Actually, you could be quite right here, Michael. In the wonderful, corporate-sponsored brainwas^H^H^H^H^H^H^H^H educational world of Disney Worlds Epcot there is an Exxon sponsored "History of Energy" run.
Allthough it's a fun run, it nearly made me barf. The kiddies are told The "history" of energy purely from the sponsors perspective and agenda. The fact that energy could actually be conserved and used responsibly was just ridiculed in one snide side remark.
It was then, when I realised that Disney is a truely and absolutly evil corporation, unmatched even by M$.
Hackers? In the land of legal weed and prostitution? The Dutch better be preparred.
While prostitution is indeed legal (as in most European countries), weed is not.
Technically speaking weed is illegal in Holland. Use however is tolerated and you can buy small amounts in coffee shops.
The cops in Holland follow the so called "Oportunitaetsprinzip (German, sorry wouldn't know the correct translation). This means in essence, that when a crime is considered chicken-shit, the cops have better things to do then fine you 50 Gilders because have two grams of grass in your posetion and should use their resources to go after really bad guys.
For the average visitor this doesn't matter much. She goes to a coffee shop, buys a baggy and puffs away. She should be aware however that in a strict sense this is not legal, and she shouldn't provoke authorities by smoking in front of the DAs office.
You can't make programs like this open source, if you did everyone would be able to walk in and steal your nuclear material.
Actually, not even a cigarette. Knowing the source code doesn't compromise security per se, provided that the coders can distinguish their arse from a hole in the ground and didn't hard code database access information into the code.
Look at encryption. Software like GnuPG and to a lesser degree PGP are open source. The algorithms applied are well documented and accessible to anybody.
Can you crack a GPG encrypted message? Not likely and it doesn't matter at all. Because security is not in the algorithm, but depends entirely on the key, possibly the chosen algorithm and the precaution of the sender and receiver.
Security through obscurity is about as dumb as it comes.
I resent that remark. I am a (technically oriented) business type and would never use a CE device.
Why? Well, easy. In a business context I don't need umpteen colors or a look and feel of a slightly monopolistic desktop operating system. I couldn't care less for an integrated MP3 player and I gladly let more gadget-oriented people enjoy the ability to play videaos on their PDAs.
So what do I expect? applications, like Titrax, which is a very simple, very straight forward time tracking application. It lets me feed the attached note into a perl script, which cranks out a detailed invoice (conveniently rounded to half hours) at the end of the month. I need simplicity. Fuck dancing paperclips that fly into my face (You seem to be looking for an address, do you need assistance?) when I actually want to look up a datebook entry. Further, I never want to tap more then two buttons to get into an application. And most of all I need reliability. I yet have to experience any data loss on my Palm Vx.
No, the palm type thingies are primitive and rediculously archaic and they might not be for everybody, but please don't imply that everybody is dumb, clueless or limited, who's job is not to crank out code in 48 hour sessions, high on JOLT.
And preserving data with 100% certainty is acheivable by anyone who takes the time to set things up right.
I don't quite buy the 100%. But very, very close to 100% is achievable. Even if you set up everything perfectly and you do have regular dumps and you do keep them off site and you adhere to each and every best practice for a system- or database admin, things can go wrong beyond your control. For example, blown hardware, corrupting both mirrors of a disk, really dumb application bugs, corrupting the database logically over time, whatever.
It's a matter of checks and balances and cost, of course. It is however very hard to achieve virtually guaranteed recoverability up to the last running transactions. For 20% of the cost however, you can achieve recoverability up to (say) a couple of hours worth of transactions. Depending on the type of data this might be quite perfect for your requirements.
For example: /. has quite different data recoverability requirements then the SWIFT (the Society for Worldwide Interbank Financial Telecommunication) network. While a days loss of/. will disgruntle a couple hundred people, 20 minutes worth of lost SWIFT message can provoke an international financial crisis.
I wouldn't think that Micro$oft is obliged to secure the server park and data of a free service as rigourous as the Federal Reserve has to secure its competers.
You are completely correct however, that $$$s overall behavior, especially in context of other service failures, lost customer data, a weeks loss of service and an information policy, compared to which your average NSA spook is as talkative as a drinking buddy in a pub after half a bottle of Tequilla is utterly unacceptable.
No sir, I wouldn't trust such amateurs with my personal data, let alone with confidential, or even company critical data; TYWM
No problem with your reasoning here. What I was referring to was the original posters (AC) Governments are the biggest corporations and not accountable.
Now, where I come from, there is a lot of accountability and - provided that you're interested - all numbers are published (and the government has strict rules on er! creative accounting practices as opposed to a corporation), all law texts are online available, etc...
Does that mean that every government official is an angel and every politician benevolent ? Well, hardly. But in terms of accountability we have far more stringent standards then corporations have.
A voice vote means that constituents back home are unable to review how their representative or senator voted. So how is
DisneyCo CEO Michael Eisner not a de facto "bad ass dictator"?
Man, you have to clean up your act, fast! Rights of the individual in the US are eroding on an alarming scale. I'm aware that this is very difficult to change, when 98% of the public couldn't care less, but it's nevertheless important to try.
Oh, yeah and I consider Mr. Eisner and cohorts absolutely ruthless dictators. The difference being that they are not in a position to torchure and kill thousands of people.
Government is the biggest and least accountable corporation there is...
Man, either you live in a rotten country of the sorts, where the CIA helps out real bad ass dictators to launch a coup against the democratically elected government, or you should seriously consider stopping to read this right-wing nutter propaganda you're apparently into.
This sort of reminds me of one of the reasons, why VMS isn't quite dead today, but smells funny; to say the least.
DEC at it's prime had a very good relationship with universities. A lot of VAXen war installed and the punters puntered happily away.
In the eighties DEC became fat, lazy and arrogant, employing too much managers & sales droids, with too little clue and too much time on their hands.
As far I recall some genius implemented a new software licensing scheme and DEC software - albeit excellent (save for the application crap) was also very expensive and DEC suddenly started to charge universities redicoulous licensing fees, which they couldn't or didn't want to afford.
Of course universities jumed to cheaper alternatives, namely U/X and it was Suns finest hour, which jumped on the chance to infiltrate the decision makers of tomorrow.
So, in terms of ever repeating history this could actually be good news...
that you should not use a public payphone to dial 1(800)443-0596 or 1(800)761-0511 if you're interested into the fine offerings of this company.
First, if you use a pay phone, this is anonymous and as we all know, who read USAtoday and Time, anonymity is used by terr0rists, kiddie pr0nographers and sm0kers of the wicked weed. Now, you surely wouldn't smoke this stuff, right? So why be anonymous ?
Also, when you call from a pay phone, those fine and ethical sound business people incurr higher costs. Now, you don't want them to pay through the nose when you dial 1(800)443-0596 or (800)761-0511 . Right ?
My girlfriend received and SMS, which was essentially stating:
CALL ME
0900-555 55 55
($3.95 a minute)
The whole spacing was intentionally, of course. And I very much suspect, that those scumbags just fired blindly into a random spectrum of phone numbers (i.e: 079 350 00 00 - 079 359 99 99).
Now, my sweetie is certainly not dumb, but she's generally not interested in the finer aspects of technology.
If I wouldn't have been around, she'd interpreted the message (CALL ME) literally and would have been out of a couple 'bucks.
Now this is not spam, in my book. This is outright fraud...
The combination of an unfair competitive position and freedom from long-term investment worries may go some way to explaining BT's financial success since privatisation.
I can't comment on MySQL, since I'm more of a Postgresql and Sybase kind of guy, but I guess that the user connection thing is comparable on all database engines:
Database users, or more accurately user connections, are probably the biggest resource hog from the database engines perspective. As an example, Sybase Adaptive Server requires ~80 byte for a lock resource, a few hundred byte per open object and and maybe a couple kb per open database. But every single configured user connection requires ~ 80kb of memory (figures from memory, they could be off).
Now you may think that 80kb is not much, when you multiply this however with 1000, we're suddenly talking 80 Mb. Those are 80 Mb ripped out from the database cache.
Now, the cache is the most fundamental concept, since no database of which I know of processes the data directly on disk, but rather in memory. So a (data)page has to be read from disk to be processed. It does also have to be written to disk, if the page changed (so called dirty page) and space is required in the cache.
Physical disk I/Os are the most darned expensive thing to expect from a relational database in terms of resources and the longer a page is available in the cache, the less likely it is, that it has to be reread from disk.
Now, memory parameters can never be configured dynamically, you can't just tear a chunk of memory out of the cache, while the db engine is operational. So memory related parameters must be configured upfront or require a reboot of the database.
The aim of a good dba is to find exactly the value(s) that not hinder operation (aka: every client can connect if he issues a request), but no configured client connections lie ideal for a long time.
This is a very boiled down version of what is internally happens in a data server, but it should provide you with the idea, why you can't configure a db in expectance that the/. readership is made aware of its existence on a sunny day.
This is simply not true. There is nothing wrong with privatisation per se.
This might be the case, if an utility is not sole supplier.
The problem is, that a profit oriented business tends to socialise costs and privatise profits. This works awfully bad for you, the customer if you only have one source for water, transportation or electricity, etc...
I agree that it might work better, when regulating bodies get more power beyond a mere slap on the wrist, which a lot of those scumbags anyway factor into their balance sheets.
You make a very valid point though, as long there is an alternative (better multiple alternatives) on the consumer front, the privatization of infrastructure might work.
Sure privatization of the telecom market definitely brought lower prices, better service (except with the former gubynmynt carrier, which is rotten as ever) and a virtually free state of the art cell phone every year (OK, you pay one way or another for that).
The real problem there seems to be the unbundling of the local loop, for which the former telephone-nazis charge uncompetitive and monopolistic inter-connection fees. And, thankfully the entire global phone system works pretty well, because it's not up to private companies to define the standards.
(OT:) Actually the global phone system is an enbelievably successful example for the client/server paradigm. No matter which client handset you use, you can connect your client with any other client throughout the world and that this works so reliabley is pretty fantastic in my book...
Meccano teaches engineering and architectural skills in a way that Lego doesn't. If we had more Meccano, we would have railways that worked.
I take it the gentleman refers to the trainsystem in ol' Blighty and I agree that it doesn't really work well; however I don't really link that to the rising popularity of Lego and the decline of Meccano, but more to the following factors:
Miss Thatchers unprecedented privatisation blizzard, which essentially wrecked all British utilities, by guaranteeing end user prices beyond believe without the necessity to invest into maintenance.
I don't think it's really efficient to split a national train system into umpteen private companies, each one of them considering stockholder profit far more important then customer satisfaction, clean trains or even security. The safety record of the British rail system is probably the worst in Europe, which brings us to another issue:
Railtrack, the infamous privatized infrastructure company, with an abyssimal track record for just about everything. Now, please repeat loud and clear: If any infrastructure of national importance is outsourced to a private entity you're fucked! The moment this happens profits are more important then the public...
You see, the UK is living proove for this fact: Watersupply, train system, electricity is about the most expensive in Europe, but provides the most rotten service to their customers. Just ask a fireman about what they did to the water pressure in order to avoid fines for water leaked through the rotten pipe system and no! the fire brigades don't consider this to be funny.
So sir, the demise of the British rail system is not due to Lego or Meccano, but due to greed, buddy favors and quite likely corrupt politicians.
Using colors on the shell is quite useful if you telnet/ssh into other boxes. That way you can easily spot what computer you're working on and not screw up on the wrong computer:).
Rats! I can either mod you up (which your post is well worth of) or comment. A conflict of interest if I've ever seen one. %-:)
Nevermind, you raise an extremely important point. In my professional work environment (where I tend to fuck around with big bastardized databases) my arse was saved more then once, by using this technique.
I might get odd looks (hey, that yellow on red is totally HORRID!!!)
But considering that such a horrid color setup definitely prevents me from issuing a DROP DATABASE CorporateCritical on the wrong telnet session is well worth the hassle
As much as I agree with you, even to the point that there is ultimately an event triggering nasty things, a reboot can (granted, very rarely) solve the problem.
Take a relational database for example; there is so much, that can go wrong with it. For starters, there are bugs in such complex products and fixing them (save for Postgresql) is beyond your control.
But it must not even be a bug in the database code. It can be something in your network component (we chased cases for month which turned out to be a DECnet issue, but where attributed to the database server), it could be the fact that the db vendor compiles his product on multiple platforms and it's virtually impossible to test every functionality of a new release on every supported platform. Yes, I know that in an ideal world this should be done, but it isn't.
Assume it would be possible to perform such tests. Save for propriatery (or semi propriatery) architectures like OpenVMS/AXP you can have so many different hardware- and network components, that it's just not possible to forsee all eventualities.
After ruling out such possibilities, we're not there yet: What are the query characteristics, how many concurrent users do when, what. What front ends do they use, how are they connected. The problem may even be caused by a component that has nothing to do with the database engine (Access front end, anyone ?)
Although the fundamental cause for the problem might never be detected a reboot of the data server might fix the problem and it will never occur again, since the same combination of factors occurs so rare that it's even impossible to reproduce the problem.
However, the [alt-ctrl-del] attitude of younger IT folks (specifically those that grew up in a PC environment) makes me barf and indicates just how clueless a lot of those folks are. You never reboot a productive IT component, unless there is no other choice or in the context of your normal maintencance cycle (memory leaks do occur in software)
Or download Adaptive Server Enterprise for Linux for free...
True enough. But when you read the license agreement it says that you can't use it in a productive environment. If you do so you need to purchase the product, which prices about comparable to the NT version (11.9.2). If you want to connect it to the internet it gets really expensive. You can use 11.0.3 for whatever you want, but that's an unsupported, end of life version (neverthelsess an excellent database engine). In a business you can absolutely not use an unsupported database.
Of course there's still no decent linux version (that I know of) of Adaptive Server Anywhere, which is, IMHO a much nicer lightweight database
It sure is a nice lightweight database, but not up to the industrial strength enterprise league in terms of robustness, security, recoverability, availability, scalability and documentation.
Adaptive Server IQ, their warehousing database.
That would be sure nice, but since Replication Server is available and developed on Linux one, as you say, still can hope.
The proper thing would have been to pay the bill in full if the suit hadn't been filed. The judge could have then proceeded with the civil suit and asked for a refund of the money.
Depending on the circumstances, I respectfully disagree. Allow me an analogy:
Here we have the option of monthly billing, or direct debit of your bank account for your credit card bills. I would never sign up for the direct debit option and here's why:
I had a couple disputes over insignificant amounts which where eventually rectified. I don't care to pay the hundred bucks on my bill, when they are credited a couple month later.
This however changes very much, when I suddenly have a $6000 item for gems purchased in Bangkok which, of course, I never bought.
Now, when do you think the CC companies customer service will be more responsive: When they have the money banked or when there's no way in hell that they see the money from me on a fraudulent purchase ever? And proceeding with a civil suit to get your money back against a major credit card company is a nuisance at best.
This attitude also derives from piss poor service I received from the local Mastercard franchise.
And in comaparancy with cable companies, credit card companies are competent professionals with a clue and happy customers is their major goal.
Cable companies, in my book, come right between time share - and used car salesmen.
One aspect that will kill them is the lack of GUI database tools. Both SQL Server and DB2 are very well equipped in this regard.
You see, I'm not really sure that this really matters.
I don't know one serious DBA in the enterprise level who prefers a GUI over SQL/shell-scripts in terms of administration.
The GUI may come in for small installations with very limited DBA expertise. And then I think it's a dangerous thing.
The thing about GUIs for complex environments is, that it just masquaredes potentially immensly complex software products.
In no way does it replace knowledge in the area of database -, or network engineering. Just having a "drop database" pull down menu item doesn't avoid table scans on HorriblyInsaneLargeTable.
Actually, you could be quite right here, Michael. In the wonderful, corporate-sponsored brainwas^H^H^H^H^H^H^H^H educational world of Disney Worlds Epcot there is an Exxon sponsored "History of Energy" run.
Allthough it's a fun run, it nearly made me barf. The kiddies are told The "history" of energy purely from the sponsors perspective and agenda. The fact that energy could actually be conserved and used responsibly was just ridiculed in one snide side remark.
It was then, when I realised that Disney is a truely and absolutly evil corporation, unmatched even by M$.
Well, one could argue, that a "speeding" motorist is more of a danger to society then a hacker smoking pot...
While prostitution is indeed legal (as in most European countries), weed is not.
Technically speaking weed is illegal in Holland. Use however is tolerated and you can buy small amounts in coffee shops.
The cops in Holland follow the so called "Oportunitaetsprinzip (German, sorry wouldn't know the correct translation). This means in essence, that when a crime is considered chicken-shit, the cops have better things to do then fine you 50 Gilders because have two grams of grass in your posetion and should use their resources to go after really bad guys.
For the average visitor this doesn't matter much. She goes to a coffee shop, buys a baggy and puffs away. She should be aware however that in a strict sense this is not legal, and she shouldn't provoke authorities by smoking in front of the DAs office.
Sensitive information in your company/government (my emphasis)
The key here is the information, which is secret, not the software that processes it.
Actually, not even a cigarette. Knowing the source code doesn't compromise security per se, provided that the coders can distinguish their arse from a hole in the ground and didn't hard code database access information into the code.
Look at encryption. Software like GnuPG and to a lesser degree PGP are open source. The algorithms applied are well documented and accessible to anybody.
Can you crack a GPG encrypted message? Not likely and it doesn't matter at all. Because security is not in the algorithm, but depends entirely on the key, possibly the chosen algorithm and the precaution of the sender and receiver.
Security through obscurity is about as dumb as it comes.
I resent that remark. I am a (technically oriented) business type and would never use a CE device.
Why? Well, easy. In a business context I don't need umpteen colors or a look and feel of a slightly monopolistic desktop operating system. I couldn't care less for an integrated MP3 player and I gladly let more gadget-oriented people enjoy the ability to play videaos on their PDAs.
So what do I expect? applications, like Titrax, which is a very simple, very straight forward time tracking application. It lets me feed the attached note into a perl script, which cranks out a detailed invoice (conveniently rounded to half hours) at the end of the month. I need simplicity. Fuck dancing paperclips that fly into my face (You seem to be looking for an address, do you need assistance?) when I actually want to look up a datebook entry. Further, I never want to tap more then two buttons to get into an application. And most of all I need reliability. I yet have to experience any data loss on my Palm Vx.
No, the palm type thingies are primitive and rediculously archaic and they might not be for everybody, but please don't imply that everybody is dumb, clueless or limited, who's job is not to crank out code in 48 hour sessions, high on JOLT.
TYVM
I don't quite buy the 100%. But very, very close to 100% is achievable. Even if you set up everything perfectly and you do have regular dumps and you do keep them off site and you adhere to each and every best practice for a system- or database admin, things can go wrong beyond your control. For example, blown hardware, corrupting both mirrors of a disk, really dumb application bugs, corrupting the database logically over time, whatever.
It's a matter of checks and balances and cost, of course. It is however very hard to achieve virtually guaranteed recoverability up to the last running transactions. For 20% of the cost however, you can achieve recoverability up to (say) a couple of hours worth of transactions. Depending on the type of data this might be quite perfect for your requirements.
For example: /. has quite different data recoverability requirements then the SWIFT (the Society for Worldwide Interbank Financial Telecommunication) network. While a days loss of /. will disgruntle a couple hundred people, 20 minutes worth of lost SWIFT message can provoke an international financial crisis.
I wouldn't think that Micro$oft is obliged to secure the server park and data of a free service as rigourous as the Federal Reserve has to secure its competers.
You are completely correct however, that $$$s overall behavior, especially in context of other service failures, lost customer data, a weeks loss of service and an information policy, compared to which your average NSA spook is as talkative as a drinking buddy in a pub after half a bottle of Tequilla is utterly unacceptable.
No sir, I wouldn't trust such amateurs with my personal data, let alone with confidential, or even company critical data; TYWM
Works like a charm, too...
Driver (picks up cell phone and tries to deciffer message on tiny display)
Car: CCRRRRRRAAAAASSSSHHHHHHHH!!!
There's a traffic congestion 300 meters in front of you, thank you for using AT&T
Now, where I come from, there is a lot of accountability and - provided that you're interested - all numbers are published (and the government has strict rules on er! creative accounting practices as opposed to a corporation), all law texts are online available, etc...
Does that mean that every government official is an angel and every politician benevolent ? Well, hardly. But in terms of accountability we have far more stringent standards then corporations have.
A voice vote means that constituents back home are unable to review how their representative or senator voted. So how is DisneyCo CEO Michael Eisner not a de facto "bad ass dictator"?
Man, you have to clean up your act, fast! Rights of the individual in the US are eroding on an alarming scale. I'm aware that this is very difficult to change, when 98% of the public couldn't care less, but it's nevertheless important to try.
Oh, yeah and I consider Mr. Eisner and cohorts absolutely ruthless dictators. The difference being that they are not in a position to torchure and kill thousands of people.
Man, either you live in a rotten country of the sorts, where the CIA helps out real bad ass dictators to launch a coup against the democratically elected government, or you should seriously consider stopping to read this right-wing nutter propaganda you're apparently into.
DEC at it's prime had a very good relationship with universities. A lot of VAXen war installed and the punters puntered happily away.
In the eighties DEC became fat, lazy and arrogant, employing too much managers & sales droids, with too little clue and too much time on their hands.
As far I recall some genius implemented a new software licensing scheme and DEC software - albeit excellent (save for the application crap) was also very expensive and DEC suddenly started to charge universities redicoulous licensing fees, which they couldn't or didn't want to afford.
Of course universities jumed to cheaper alternatives, namely U/X and it was Suns finest hour, which jumped on the chance to infiltrate the decision makers of tomorrow.
So, in terms of ever repeating history this could actually be good news...
First, if you use a pay phone, this is anonymous and as we all know, who read USAtoday and Time, anonymity is used by terr0rists, kiddie pr0nographers and sm0kers of the wicked weed. Now, you surely wouldn't smoke this stuff, right? So why be anonymous ?
Also, when you call from a pay phone, those fine and ethical sound business people incurr higher costs. Now, you don't want them to pay through the nose when you dial 1(800)443-0596 or (800)761-0511 . Right ?
CALL ME
0900-555 55 55
($3.95 a minute)
The whole spacing was intentionally, of course. And I very much suspect, that those scumbags just fired blindly into a random spectrum of phone numbers (i.e: 079 350 00 00 - 079 359 99 99).
Now, my sweetie is certainly not dumb, but she's generally not interested in the finer aspects of technology.
If I wouldn't have been around, she'd interpreted the message (CALL ME) literally and would have been out of a couple 'bucks.
Now this is not spam, in my book. This is outright fraud...
rats! And I was sure you was talking about the phone company from hell .
Else then that, I couldn't have expressed so eloquently what's so damn wrong with the current privatization blitz.
Database users, or more accurately user connections, are probably the biggest resource hog from the database engines perspective. As an example, Sybase Adaptive Server requires ~80 byte for a lock resource, a few hundred byte per open object and and maybe a couple kb per open database. But every single configured user connection requires ~ 80kb of memory (figures from memory, they could be off).
Now you may think that 80kb is not much, when you multiply this however with 1000, we're suddenly talking 80 Mb. Those are 80 Mb ripped out from the database cache.
Now, the cache is the most fundamental concept, since no database of which I know of processes the data directly on disk, but rather in memory. So a (data)page has to be read from disk to be processed. It does also have to be written to disk, if the page changed (so called dirty page) and space is required in the cache.
Physical disk I/Os are the most darned expensive thing to expect from a relational database in terms of resources and the longer a page is available in the cache, the less likely it is, that it has to be reread from disk.
Now, memory parameters can never be configured dynamically, you can't just tear a chunk of memory out of the cache, while the db engine is operational. So memory related parameters must be configured upfront or require a reboot of the database.
The aim of a good dba is to find exactly the value(s) that not hinder operation (aka: every client can connect if he issues a request), but no configured client connections lie ideal for a long time.
This is a very boiled down version of what is internally happens in a data server, but it should provide you with the idea, why you can't configure a db in expectance that the /. readership is made aware of its existence on a sunny day.
Parents: Why do you listen to this beatles shit, this is just noise and has no value, yadayadayada
The irony of course is that nowadays:
Me: How can you listen to this techno stuff, it's just noise and has no value, yadayadayada
Er! well, never mind...
This might be the case, if an utility is not sole supplier.
The problem is, that a profit oriented business tends to socialise costs and privatise profits. This works awfully bad for you, the customer if you only have one source for water, transportation or electricity, etc...
I agree that it might work better, when regulating bodies get more power beyond a mere slap on the wrist, which a lot of those scumbags anyway factor into their balance sheets.
OK: I issue a recall for any %-:')
You make a very valid point though, as long there is an alternative (better multiple alternatives) on the consumer front, the privatization of infrastructure might work.
Sure privatization of the telecom market definitely brought lower prices, better service (except with the former gubynmynt carrier, which is rotten as ever) and a virtually free state of the art cell phone every year (OK, you pay one way or another for that).
The real problem there seems to be the unbundling of the local loop, for which the former telephone-nazis charge uncompetitive and monopolistic inter-connection fees. And, thankfully the entire global phone system works pretty well, because it's not up to private companies to define the standards.
(OT:) Actually the global phone system is an enbelievably successful example for the client/server paradigm. No matter which client handset you use, you can connect your client with any other client throughout the world and that this works so reliabley is pretty fantastic in my book...
I take it the gentleman refers to the trainsystem in ol' Blighty and I agree that it doesn't really work well; however I don't really link that to the rising popularity of Lego and the decline of Meccano, but more to the following factors:
Miss Thatchers unprecedented privatisation blizzard, which essentially wrecked all British utilities, by guaranteeing end user prices beyond believe without the necessity to invest into maintenance.
I don't think it's really efficient to split a national train system into umpteen private companies, each one of them considering stockholder profit far more important then customer satisfaction, clean trains or even security. The safety record of the British rail system is probably the worst in Europe, which brings us to another issue:
Railtrack, the infamous privatized infrastructure company, with an abyssimal track record for just about everything. Now, please repeat loud and clear: If any infrastructure of national importance is outsourced to a private entity you're fucked! The moment this happens profits are more important then the public...
You see, the UK is living proove for this fact: Watersupply, train system, electricity is about the most expensive in Europe, but provides the most rotten service to their customers. Just ask a fireman about what they did to the water pressure in order to avoid fines for water leaked through the rotten pipe system and no! the fire brigades don't consider this to be funny.
So sir, the demise of the British rail system is not due to Lego or Meccano, but due to greed, buddy favors and quite likely corrupt politicians.
No need to thank me...
Rats! I can either mod you up (which your post is well worth of) or comment. A conflict of interest if I've ever seen one. %-:)
Nevermind, you raise an extremely important point. In my professional work environment (where I tend to fuck around with big bastardized databases) my arse was saved more then once, by using this technique.
I might get odd looks (hey, that yellow on red is totally HORRID!!!)
But considering that such a horrid color setup definitely prevents me from issuing a DROP DATABASE CorporateCritical on the wrong telnet session is well worth the hassle
Take a relational database for example; there is so much, that can go wrong with it. For starters, there are bugs in such complex products and fixing them (save for Postgresql) is beyond your control.
But it must not even be a bug in the database code. It can be something in your network component (we chased cases for month which turned out to be a DECnet issue, but where attributed to the database server), it could be the fact that the db vendor compiles his product on multiple platforms and it's virtually impossible to test every functionality of a new release on every supported platform. Yes, I know that in an ideal world this should be done, but it isn't.
Assume it would be possible to perform such tests. Save for propriatery (or semi propriatery) architectures like OpenVMS/AXP you can have so many different hardware- and network components, that it's just not possible to forsee all eventualities.
After ruling out such possibilities, we're not there yet: What are the query characteristics, how many concurrent users do when, what. What front ends do they use, how are they connected. The problem may even be caused by a component that has nothing to do with the database engine (Access front end, anyone ?)
Although the fundamental cause for the problem might never be detected a reboot of the data server might fix the problem and it will never occur again, since the same combination of factors occurs so rare that it's even impossible to reproduce the problem.
However, the [alt-ctrl-del] attitude of younger IT folks (specifically those that grew up in a PC environment) makes me barf and indicates just how clueless a lot of those folks are. You never reboot a productive IT component, unless there is no other choice or in the context of your normal maintencance cycle (memory leaks do occur in software)
True enough. But when you read the license agreement it says that you can't use it in a productive environment. If you do so you need to purchase the product, which prices about comparable to the NT version (11.9.2). If you want to connect it to the internet it gets really expensive. You can use 11.0.3 for whatever you want, but that's an unsupported, end of life version (neverthelsess an excellent database engine). In a business you can absolutely not use an unsupported database.
Of course there's still no decent linux version (that I know of) of Adaptive Server Anywhere, which is, IMHO a much nicer lightweight database
It sure is a nice lightweight database, but not up to the industrial strength enterprise league in terms of robustness, security, recoverability, availability, scalability and documentation.
Adaptive Server IQ, their warehousing database.
That would be sure nice, but since Replication Server is available and developed on Linux one, as you say, still can hope.
Depending on the circumstances, I respectfully disagree. Allow me an analogy:
Here we have the option of monthly billing, or direct debit of your bank account for your credit card bills. I would never sign up for the direct debit option and here's why:
I had a couple disputes over insignificant amounts which where eventually rectified. I don't care to pay the hundred bucks on my bill, when they are credited a couple month later.
This however changes very much, when I suddenly have a $6000 item for gems purchased in Bangkok which, of course, I never bought.
Now, when do you think the CC companies customer service will be more responsive: When they have the money banked or when there's no way in hell that they see the money from me on a fraudulent purchase ever? And proceeding with a civil suit to get your money back against a major credit card company is a nuisance at best.
This attitude also derives from piss poor service I received from the local Mastercard franchise.
And in comaparancy with cable companies, credit card companies are competent professionals with a clue and happy customers is their major goal.
Cable companies, in my book, come right between time share - and used car salesmen.
You see, I'm not really sure that this really matters.
I don't know one serious DBA in the enterprise level who prefers a GUI over SQL/shell-scripts in terms of administration.
The GUI may come in for small installations with very limited DBA expertise. And then I think it's a dangerous thing.
The thing about GUIs for complex environments is, that it just masquaredes potentially immensly complex software products.
In no way does it replace knowledge in the area of database -, or network engineering. Just having a "drop database" pull down menu item doesn't avoid table scans on HorriblyInsaneLargeTable.