That sounds great - but the reality is that engineers have discovered that much of their field has relocated overseas, and that it starts to become difficult to stay employed, competitive and current after 25 years in the field. Of course, it's possible - I've been working in the field for 30 years, continue to love it, and have no problems with employment. But there are 10 people who've dropped out for every person such as myself - and the reality is that CS is only a half-career - something that you can only do for the first half of your life with any certainty. So, it's worth being practical.
> If his passion is mathematics, there is much more available than being a data analyst
Right - I'm using generic terms since I don't know what exactly he might end up doing: machine learning? statistician? data mining?
He's interested in both fields - and feels that he could probably do more programming and math as a mathematician of some sort than as a CS major - who may end up as yet-another application developer doing very little math and constantly racing to stay current.
That's a risky strategy - a lot of those guys lost their jobs during the y2k conversion from in-house to ERP apps.
I'm 47 and develop using python and parallel databases. My strategy is to continue to be an expert at data management - data quality, data logistics, various types of databases, reporting, data warehousing, scoring and analytics. I think I'll be able to hang in there until I'm 65.
The challenge is that when I'm 55+ I probably won't be up for 60 hour weeks. So, I'm definitely assuming that I'll need to start to stick with the 40 hour work week at some point in the future.
I've got two kids to put through college - and they are both very skilled and capable of going to some of the best schools in the country where their combined bills could come to $500,000.
Then there's retirement - potentially without much social security thanks to the far right.
Then there's the possibility of getting an injury or illness - again, with very little safety net.
I'd do far better living off $60k in western europe.
So, a number of salary surveys have shown that engineers hit their peak salary around the age of 45-55, but it then declines. This is quite the opposite of very many fields - lawyers, doctors, etc can work until they are 70.
My son is planning to major in math and just take a minor in computer science, then work as a data analyst. What do you think?
> If you want to use Postgres, fine. Use it. But you make yourself look very small when you go out of > your way to put down such a fine project as MySQL just because your Postgres can do... what... oh yeah - you didn't even mention.
LOL, please - do yourself a favor and spend some time on the mysql pages looking at their bug reports. Pay special attention to all the 'silent failures' that can lead to data corruption.
Then look into what MySQL AB has said about transaction, triggers, stored procedures, views, subselects, etc in the past. That you don't need them. Then consider what we've learned about databases over the past 40 years, and decide if that advise is worth anything is or just misinformation.
Then look at the likelihood of having to pay mysql licensing feeds.
We used to use mysql at my office. It's been abandoned in favor of postgresql for the following primary reasons:
- porting difficult
- licensing complexity
- data corruption problems Now, note that we're primarily a db2 shop. But that we've got db2, oracle, postgresql, sql server, and mysql. I've used them all, though am most experienced with db2 (18 years of experience there). I've got no problem with us bringing aboard another database if that makes sense. But the mysql problems are serious and unique. Until they are resolved it will stay on the b-list...
> Aaargh. Can we get rid of this stupid meme, please? I've been making a living as a DBA for > almost five years now. I'm 2/3 of the way to a CS Master's. I've used Oracle, Sybase, and PostgreSQL. > And I prefer MySQL. The idea that the only people who use MySQL are those who don't know any better has to die.
You're right, it should be used by people developing applications for wide dissemination across web hosting facilities - since right now it has the greatest number of hosting providers of any database.
But aside from that? Why should we use it?
- non-standard SQL
- lack of common capabilities (views, etc)
- silent failures are common
- mysql ab has often stated that we just don't need transactions, views, subselects, etc (!)
- concurrent write performance appears poor
- vendor has submit no tpc benchmarks
So, given that there are cheaper, more fully featured, more portable alternatives...I'd have to say that only people who didn't know any better would use it.
Perhaps, as an 'experienced dba' you would be prepared to talk about how mysql administration is superior to that of other databases. Please be sure to cover innodb configuration silent errors, online backups without additional commercial licensing, and repairs of data corruption caused by silent constraint failures.
> I've been reviewing and making infrastructure architecture recommendations for 6 years. My > experience has been that the people who can demonstrate scale and efficiency tend to choose > systems that do not bottleneck the database. I have used mysql, postgres, as well as oracle. > Generally people say that mysql is limited in features, but is that a bad thing?
Well, first off I think most complaints about msyql aren't about performance. It has fine read performance, though concurrent write performance seems poor. Haven't been able to run any benchmarks to prove that, just what I'm observing and hearing. MySQL is strangely silent on TCP-Cs. But for many small apps - the performance is good enough. The real problems are licensing, silent errors, non-compatible sql, etc.
yes it's a bad thing - since they aren't complaining about features - like a cup-holder in a car. They're complaining about features like a standard 12v electrical system in the car:
- least portable sql of any common database
- lack of support for basic, 20 year old database features like views
- transactions only available thru third-party product, not seamlessly integrated in mysql, often fails to work silently (!)
mysql ab has often stated that transactions (!), views, subselects, triggers, stored procs are unnecessary for 90% of the users out there. This is deliberate misinformation. Sure, you can live without stored procs, and sometimes triggers. But subselects? views? transactions? Heck, even a simple bowling-score hobby database should use transactions - implementing transactions in your application is *far* simpler than dealing with corrupt data!
> Can someone with the deep experience (in both systems), and some spare time, please create a feature/fault matrix for both production and > development versions of mysql and posgres and submit the link as a reply? It wouldn't hurt to throw in oracle/DB2 to see what repaying for your > software every year gets you.
Please, doing that for postgresql, mysql, oracle, and db2 (and for both dev & prod versions) at any level of detail would be extremely time-consuming. The ideal technique here is to score the solutions based upon very low-level critieria (support for super-groups in sql, etc) then roll it up. Since each product does some things a little differently you're looking at 200 hours to pull this off.
This kind of task, along with performance benchmarks (tpc-c & tpc-h) are often done for very large projects. Maybe we'll see at least some benchmarks come from a hardware manufucturer one of these days. Or mysql if it felt that it was mature enough to compete with the commercial databasees - then it would spend some of that investor money to prove it.
> Yes, things definately have soured in the MySql camp from an ambush of Postgres Users.
Maybe it could have something to do with mysql ab misinforming people for years on a variety of subjects (basic sql & transactions not needed, etc)?
Maybe it could have something to do with the discovery that mysql just silently fails on a wide variety of errors without informing the client?
Maybe it could have something to do with mysql ab's apparent conflict of interest over their dual licensing? Perhaps some folks are looking at the writing on the wall and seeing commercial licenses being required for most mysql use in five years.
Maybe these users have discovered that postgresql (free), and firebird (very inexpensive) are more impressive competitors (read: built-in transactions along with ANSI SQL compatibility) with none of the licensing nonsense?
> The wonderful thing, in my opinion, MySQL based applications tend to be installed very easily, on different platforms, and this includes examples > that I am personally responsble for (http://www.silverstripe.com/ ).
Yes, this is a wonderful thing, and probably the main reason for its success. Unfortunately for mysql postgresql is about to offer the same thing on windows.
> That's not much help if you're supposed to be working with XML.
It's a simple example of the types of recursion that you can use to traverse hierarchies within sql. So, depending on how XML is implemented within the database, this capability might be used to query xml data.
> I looked up the WITH keyword in my MS SQL docs, and it appears to be part of MDX (for OLAP cubes, > I think), rather than SQL.
I played with recursion within MS SQL back around 2000-2001. At that time (using SQL Server 2000) their recursion capability was provided via stored procedure source code they provided. Which unfortunately had a few glaring errors in it and basically didn't work. With modifications it could, but was still primitive compared to DB2 & Oracle.
> I don't know of anything that supports a single counter for the entire database (directly -- you can > always use a NextID table, but you then have to do iterative inserts), but using a GUID in MS-SQL does > seem to be fairly common, and I think it has a function to generate them. The downside is that you > then have 128 bit keys rather than 32, which will cause a performance hit.
Actually both Oracle & DB2 support this. It's called a sequence in db2 (vs an identity which is table-specific).
The other benefit of not having your object ids tied to a physical schema implementation is that you can remodel your schema - without many concerns about having to convert primary keys.
> Here in Virginia, the concealed carry permit allows one to do an imitation of Dirty Harry. >A lead induced lobotomy cures most criminal impulses.
And even more importantly - allows the user to feel like a well-hung man. Of course, this feeling is only temporary, but that's ok - because you can also buy an attack dog and suv to fend off the inevitable creeping insecurities.
There's nothing more pathetic than a geek with a gun getting his ass completely kicked while trying to get his weapon out of his colastomy-bag-looking hip-sack. The only upside is the entertainment that it gives everyone around him lived through years of his tough-talking. Of course, the ever-so-resourceful-insecure-geek might then become even more obnoxious, by keeping his gun in his hand at all times, so that he can 'squeeze one off' before getting throttled. Luckily at that point he's almost guaranteed to get beaten to death, and end everyone else's misery.
Seriously, every geek I've ever met that has insisted he needed a gun also lived in about the safest part of town you could ever find. Then he avoided anyplace more dangerous than a theme park. I suppose there's someone out there that actually would benefit from carrying a gun, but I have yet to meet the geek that did.
you're going to get a lot of comments like:
- learn martial arts
- lift weights
- grow 14 inches
- carry a gun/knife/mace/morning star/etc
- etc
But seriously, the best option is avoidance:
- avoid looking like a victim - don't carry
things of conspicuous value
- avoid places where you're likely to get mugged
- stay alert - muggers seldom target people who appear very alert to their surroundings and confident
Many years ago I used to rely on fighting to defend myself - but sometimes ended up in fights with people who had *nothing* to loose. Later on I discovered how to simply avoid the places attractive to those people and to be very alert when occasionally there. This works so much better than fighting you won't believe it.
> Admittedly, not nearly as complex as the Oracle one (nothing like a poster of reserved words to keep
> you company at work). And yet, has Oracle gone away? Not really.
While oracle is a pain-in-the-ass, it doesn't have this kind of confusion.
It has both proprietary & ANSI metadata tables, quite a few system & user functions, a fairly simple language, and a fair amount of reserved words. There's quite a bit of complexity there, but most users will only touch on 10% of it, and there is typically just a very limited number of ways of doing the exact same thing.
Perl on the other hand, has about six gazillion ways of doing the exact same thing. And reading another coder's work can require hours of analysis *of the stinking language* rather than of the solution.
Nope, this is a disaster, and even the bloated beast that is Oracle looks reasonable in comparison. I can't think of a better reason for getting serious about python or ruby....
> The flaw in your logic is that there has been no documented incident of accidental launch of a nuclear > missile.
No - that's like saying the security system at my apartment isn't broken since nothing has been stolen - in spite of multiple broken locks that anyone could bypass. So, just because no accidental launch has occured (yet) doesn't mean it couldn't happen much more easily than the military would like us to believe.
> The password strength is irrelevant because of > the many levels of failure which were necessary > to result in an unauthorized launch, be they > internal or external, any one of which would have > triggered a fail-safe scenario.
But again - why would you have any confidence in the implementation of the other layers when you discover blatant incompetence in this layer? That's like taking your car to a mechanic, and have them fail to put all lug nuts back on your wheels. Why would you think they did anything else competently?
BTW, this isn't to say that it would be trivial to compromise the many layers of defense. Just that the security may be just 10% as strong as they'd like us to believe.
so...you're claiming that this absurdly stupid password is irrelevant because there are additional layers of security.
ok...and you have confidence that those were implemented well - by the very same people who choose 00000000 as their password?
nah, this fails a simple sanity-check - odds are that all of those layers were implemented about as poorly as this one.
In the end, we had a bunch of bozos in charge of nuclear weapons. Not much different than Dr Strangelove after all.
Keep in mind that many tools fail in catastrophic and *non-intuitive* ways, and people do not always have a choice of what tools they get to use (except perhaps in some theoretical Ayn Rand world). It is unreasonable to hold users responsible for failure modes that are not obvious - but that the engineers of the product are aware of. There are, of course, special cases in which protecting the users from harm is nearly impossible. However, there are many cases in which a simple design element can save lives & limbs.
When a company is too cheap to spend $0.14 on a deadmans switch for a large machine that requires someone to climb inside to repair - and a few people die each year because of the combined savings of $3.72 - we've got a problem. Fortunately, the courts solved that problem.
Back to the original subject: a software tool that very easily fails in a way that is hazardous, when this could easily be prevented - is flawed. It isn't the 'bad workman' it's the 'bad tool'.
> Have iterations, yes, but a project can really be delayed if a project manager doesn't put manage
> expectations and suggest that interface issues should be change requests after delivery as to let
> users work on it for an extended period of time. By then, they will have a better idea of what they
> want, and effort won't be duplicated (and triplicated).
Sure - managing expectations is critical. And if the users and the project manager have a good relationship that can work. But if they don't - the users can get screwed - when the development team returns as estimate for work they don't want to do - that is rediculously high.
I think one of the biggest problems here is the typical outsourcing model - which you mention earlier in your post - and that just about forces waterfall development.
GreyWolf3000 wrote:
> where labor unions drive up the price of Ice Cream to 5 or 6 dollars a scoop
Yep, the dps (dollar per scoop) metric has many long-overlooked benefits:
1. enables concise regional comparisons
2. identifies regions that might be controlled by them pesky commie/atheist/labor/lefty types - who, like the mafia and garbage, use their domination of ice-cream parlors in the NE to peddle their wares.
Remember the Alamo!
Whoa - cool!
I hadn't seen that, but will have to check it out.
The standard language is a lot of big shops (including mine) is java. But java (especially j2ee) is so anti-productive that I'm always looking for excuses to use something else.
My strategy lately has been to use python - since it can be evolved into jython, then eventually to java if necessary.
But rexx is also a db2 procedure language (along with visual basic, java, c, c++).
Netrexx should have a place next to python now - as a simple language with a seamless upgrade path.
Rexx was incredibly cool at the time:
- implemented on a dozen platforms
- code was multi-platform
- extremely easy to use / easy to extend / easy to maintain
- could run it from MVS JCL
- was the macro language for ISPF
I used rexx for the following:
- converted hundreds of cobol programs from cobol 68 to COBOL II (required parsing code, replacing periods with end-ifs, end-searchs, etc)
- created 'asserts' for several programming languages - in which a simple function key would confirm the syntax.
- created 'point & click' character interfaces - in which a function key would look up whatever was at the current cursor location and open an ISPF browser window on that file.
And the above code was *easy*.
Today I'm writing a lot of code in ksh & python. If python wasn't around I'd probably create this code in rexx. Although it's harder to find support for than bash - it a far better language. And although perl is more powerful in some ways - it isn't the maintenance-disaster that perl is.
But python is just simply too good a language. Too bad for Rexx.
A papertrail just gives a false sense of security - this is like a database transaction problem.
Who says that just because you've got a paper receipt that the machine used the same electronic results?
The *only* way to get around this is for the machine to produce a human-readable printout - which is then counted by a simple local mechanical machine. Then those same printouts are sent up to be counted again at the county level, then again up at the state level.
This would allow anyone to easily balance the counts at the individual, preceint, county, and state level. Everything could be easily audited and any mistakes in logistics identified.
Just about all other solutions I've seen require faith in some part of the system. What I'm recommending here isn't convenient, and is labor-intensive. But who cares? We're talking about voting right? So, spend a little time on it. Hell, don't the Canadians have a completely manual system?
> Well, Python is dynamically typed for one. Dynamic typing is great for scripting languages
> because the language gets out of your way and the rules are laxer, so you can work quicker. It's
> not so great for larger or more complex pieces of code where robustness is more important than
> having fewer rules.
In theory perhaps. But I'm seeing python used in larger & larger applications - and believe any problems created by dynamic typing are more than compensated for by its simplicity.
> Python has a few other problems. It's (a) slow even with tools like Psyco
Really? Makes you wonder about claims like - "visual basic is what really made windows a success". How could such a slow, interpreted language like vb work so well for windows - on 486-66s?
> and (b) has a wierd non-C like syntax which is a bit offputting for people who are used to
> C++/Java/C# style languages.
any c++/java/c# programmer worth his salt should be able to pick up python almost immediately. It's simple and intuitive. And the use of whitespace to enforce nesting consistency hardly makes the syntax 'weird'.
Slashdot Mirror
> If your son's passion is CS then do CS.
That sounds great - but the reality is that engineers have discovered that much of their field has relocated overseas, and that it starts to become difficult to stay employed, competitive and current after 25 years in the field. Of course, it's possible - I've been working in the field for 30 years, continue to love it, and have no problems with employment. But there are 10 people who've dropped out for every person such as myself - and the reality is that CS is only a half-career - something that you can only do for the first half of your life with any certainty. So, it's worth being practical.
> If his passion is mathematics, there is much more available than being a data analyst
Right - I'm using generic terms since I don't know what exactly he might end up doing: machine learning? statistician? data mining?
He's interested in both fields - and feels that he could probably do more programming and math as a mathematician of some sort than as a CS major - who may end up as yet-another application developer doing very little math and constantly racing to stay current.
That's a risky strategy - a lot of those guys lost their jobs during the y2k conversion from in-house to ERP apps.
I'm 47 and develop using python and parallel databases. My strategy is to continue to be an expert at data management - data quality, data logistics, various types of databases, reporting, data warehousing, scoring and analytics. I think I'll be able to hang in there until I'm 65.
The challenge is that when I'm 55+ I probably won't be up for 60 hour weeks. So, I'm definitely assuming that I'll need to start to stick with the 40 hour work week at some point in the future.
It's amazing how much your style matters when you walk in the door and meet people for the first time.
One of the most impressive developers I've ever known had a very hard time with first impressions because of his white hair.
I can vouch for this.
I've got two kids to put through college - and they are both very skilled and capable of going to some of the best schools in the country where their combined bills could come to $500,000.
Then there's retirement - potentially without much social security thanks to the far right.
Then there's the possibility of getting an injury or illness - again, with very little safety net.
I'd do far better living off $60k in western europe.
So, a number of salary surveys have shown that engineers hit their peak salary around the age of 45-55, but it then declines. This is quite the opposite of very many fields - lawyers, doctors, etc can work until they are 70.
My son is planning to major in math and just take a minor in computer science, then work as a data analyst. What do you think?
> If you want to use Postgres, fine. Use it. But you make yourself look very small when you go out of ... what ... oh yeah - you didn't even mention.
> your way to put down such a fine project as MySQL just because your Postgres can do
LOL, please - do yourself a favor and spend some time on the mysql pages looking at their bug reports. Pay special attention to all the 'silent failures' that can lead to data corruption.
Then look into what MySQL AB has said about transaction, triggers, stored procedures, views, subselects, etc in the past. That you don't need them. Then consider what we've learned about databases over the past 40 years, and decide if that advise is worth anything is or just misinformation.
Then look at the likelihood of having to pay mysql licensing feeds.
We used to use mysql at my office. It's been abandoned in favor of postgresql for the following primary reasons:
- porting difficult
- licensing complexity
- data corruption problems
Now, note that we're primarily a db2 shop. But that we've got db2, oracle, postgresql, sql server, and mysql. I've used them all, though am most experienced with db2 (18 years of experience there). I've got no problem with us bringing aboard another database if that makes sense. But the mysql problems are serious and unique. Until they are resolved it will stay on the b-list...
> Aaargh. Can we get rid of this stupid meme, please? I've been making a living as a DBA for
> almost five years now. I'm 2/3 of the way to a CS Master's. I've used Oracle, Sybase, and PostgreSQL.
> And I prefer MySQL. The idea that the only people who use MySQL are those who don't know any better has to die.
You're right, it should be used by people developing applications for wide dissemination across web hosting facilities - since right now it has the greatest number of hosting providers of any database.
But aside from that? Why should we use it?
- non-standard SQL
- lack of common capabilities (views, etc)
- silent failures are common
- mysql ab has often stated that we just don't need transactions, views, subselects, etc (!)
- concurrent write performance appears poor
- vendor has submit no tpc benchmarks
So, given that there are cheaper, more fully featured, more portable alternatives...I'd have to say that only people who didn't know any better would use it.
Perhaps, as an 'experienced dba' you would be prepared to talk about how mysql administration is superior to that of other databases. Please be sure to cover innodb configuration silent errors, online backups without additional commercial licensing, and repairs of data corruption caused by silent constraint failures.
> I've been reviewing and making infrastructure architecture recommendations for 6 years. My
> experience has been that the people who can demonstrate scale and efficiency tend to choose
> systems that do not bottleneck the database. I have used mysql, postgres, as well as oracle.
> Generally people say that mysql is limited in
features, but is that a bad thing?
Well, first off I think most complaints about msyql aren't about performance. It has fine read performance, though concurrent write performance seems poor. Haven't been able to run any benchmarks to prove that, just what I'm observing and hearing. MySQL is strangely silent on TCP-Cs. But for many small apps - the performance is good enough. The real problems are licensing, silent errors, non-compatible sql, etc.
yes it's a bad thing - since they aren't complaining about features - like a cup-holder in a car. They're complaining about features like a standard 12v electrical system in the car:
- least portable sql of any common database
- lack of support for basic, 20 year old database features like views
- transactions only available thru third-party product, not seamlessly integrated in mysql, often fails to work silently (!)
mysql ab has often stated that transactions (!), views, subselects, triggers, stored procs are unnecessary for 90% of the users out there. This is deliberate misinformation. Sure, you can live without stored procs, and sometimes triggers. But subselects? views? transactions? Heck, even a simple bowling-score hobby database should use transactions - implementing transactions in your application is *far* simpler than dealing with corrupt data!
> Can someone with the deep experience (in both systems), and some spare time, please create a feature/fault matrix for both production and
> development versions of mysql and posgres and submit the link as a reply? It wouldn't hurt to throw in oracle/DB2 to see what repaying for your
> software every year gets you.
Please, doing that for postgresql, mysql, oracle, and db2 (and for both dev & prod versions) at any level of detail would be extremely time-consuming. The ideal technique here is to score the solutions based upon very low-level critieria (support for super-groups in sql, etc) then roll it up. Since each product does some things a little differently you're looking at 200 hours to pull this off.
This kind of task, along with performance benchmarks (tpc-c & tpc-h) are often done for very large projects. Maybe we'll see at least some benchmarks come from a hardware manufucturer one of these days. Or mysql if it felt that it was mature enough to compete with the commercial databasees - then it would spend some of that investor money to prove it.
> Yes, things definately have soured in the MySql camp from an ambush of Postgres Users.
Maybe it could have something to do with mysql ab misinforming people for years on a variety of subjects (basic sql & transactions not needed, etc)?
Maybe it could have something to do with the discovery that mysql just silently fails on a wide variety of errors without informing the client?
Maybe it could have something to do with mysql ab's apparent conflict of interest over their dual licensing? Perhaps some folks are looking at the writing on the wall and seeing commercial licenses being required for most mysql use in five years.
Maybe these users have discovered that postgresql (free), and firebird (very inexpensive) are more impressive competitors (read: built-in transactions along with ANSI SQL compatibility) with none of the licensing nonsense?
> The wonderful thing, in my opinion, MySQL based applications tend to be installed very easily, on different platforms, and this includes examples
> that I am personally responsble for (http://www.silverstripe.com/ ).
Yes, this is a wonderful thing, and probably the main reason for its success. Unfortunately for mysql postgresql is about to offer the same thing on windows.
buck
or an OO database - designed for small indexed retrievals of a few objects rather than bulk operations.
or an ancient hierarchical database (IMS DB) with the same problems.
or a shiney new hierarchical xml database with the same problems.
So yeah, the problem is rediculous. But not really that uncommon.
> That's not much help if you're supposed to be working with XML.
It's a simple example of the types of recursion that you can use to traverse hierarchies within sql. So, depending on how XML is implemented within the database, this capability might be used to query xml data.
> I looked up the WITH keyword in my MS SQL docs, and it appears to be part of MDX (for OLAP cubes,
> I think), rather than SQL.
I played with recursion within MS SQL back around 2000-2001. At that time (using SQL Server 2000) their recursion capability was provided via stored procedure source code they provided. Which unfortunately had a few glaring errors in it and basically didn't work. With modifications it could, but was still primitive compared to DB2 & Oracle.
> I don't know of anything that supports a single counter for the entire database (directly -- you can
> always use a NextID table, but you then have to do
iterative inserts), but using a GUID in MS-SQL does
> seem to be fairly common, and I think it has a function to generate them. The downside is that you
> then have 128 bit keys rather than 32, which will cause a performance hit.
Actually both Oracle & DB2 support this. It's called a sequence in db2 (vs an identity which is table-specific).
The other benefit of not having your object ids tied to a physical schema implementation is that you can remodel your schema - without many concerns about having to convert primary keys.
> Here in Virginia, the concealed carry permit allows one to do an imitation of Dirty Harry.
>A lead induced lobotomy cures most criminal impulses.
And even more importantly - allows the user to feel like a well-hung man. Of course, this feeling is only temporary, but that's ok - because you can also buy an attack dog and suv to fend off the inevitable creeping insecurities.
There's nothing more pathetic than a geek with a gun getting his ass completely kicked while trying to get his weapon out of his colastomy-bag-looking hip-sack. The only upside is the entertainment that it gives everyone around him lived through years of his tough-talking. Of course, the ever-so-resourceful-insecure-geek might then become even more obnoxious, by keeping his gun in his hand at all times, so that he can 'squeeze one off' before getting throttled. Luckily at that point he's almost guaranteed to get beaten to death, and end everyone else's misery.
Seriously, every geek I've ever met that has insisted he needed a gun also lived in about the safest part of town you could ever find. Then he avoided anyplace more dangerous than a theme park. I suppose there's someone out there that actually would benefit from carrying a gun, but I have yet to meet the geek that did.
you're going to get a lot of comments like:
- learn martial arts
- lift weights
- grow 14 inches
- carry a gun/knife/mace/morning star/etc
- etc
But seriously, the best option is avoidance:
- avoid looking like a victim - don't carry
things of conspicuous value
- avoid places where you're likely to get mugged
- stay alert - muggers seldom target people who appear very alert to their surroundings and confident
Many years ago I used to rely on fighting to defend myself - but sometimes ended up in fights with people who had *nothing* to loose. Later on I discovered how to simply avoid the places attractive to those people and to be very alert when occasionally there. This works so much better than fighting you won't believe it.
> Admittedly, not nearly as complex as the Oracle one (nothing like a poster of reserved words to keep > you company at work). And yet, has Oracle gone away? Not really. While oracle is a pain-in-the-ass, it doesn't have this kind of confusion. It has both proprietary & ANSI metadata tables, quite a few system & user functions, a fairly simple language, and a fair amount of reserved words. There's quite a bit of complexity there, but most users will only touch on 10% of it, and there is typically just a very limited number of ways of doing the exact same thing. Perl on the other hand, has about six gazillion ways of doing the exact same thing. And reading another coder's work can require hours of analysis *of the stinking language* rather than of the solution. Nope, this is a disaster, and even the bloated beast that is Oracle looks reasonable in comparison. I can't think of a better reason for getting serious about python or ruby....
> The flaw in your logic is that there has been no documented incident of accidental launch of a nuclear
> missile.
No - that's like saying the security system at my apartment isn't broken since nothing has been stolen - in spite of multiple broken locks that anyone could bypass. So, just because no accidental launch has occured (yet) doesn't mean it couldn't happen much more easily than the military would like us to believe.
> The password strength is irrelevant because of
> the many levels of failure which were necessary
> to result in an unauthorized launch, be they
> internal or external, any one of which would have
> triggered a fail-safe scenario.
But again - why would you have any confidence in the implementation of the other layers when you discover blatant incompetence in this layer? That's like taking your car to a mechanic, and have them fail to put all lug nuts back on your wheels. Why would you think they did anything else competently?
BTW, this isn't to say that it would be trivial to compromise the many layers of defense. Just that the security may be just 10% as strong as they'd like us to believe.
so...you're claiming that this absurdly stupid password is irrelevant because there are additional layers of security. ok...and you have confidence that those were implemented well - by the very same people who choose 00000000 as their password? nah, this fails a simple sanity-check - odds are that all of those layers were implemented about as poorly as this one. In the end, we had a bunch of bozos in charge of nuclear weapons. Not much different than Dr Strangelove after all.
Keep in mind that many tools fail in catastrophic and *non-intuitive* ways, and people do not always have a choice of what tools they get to use (except perhaps in some theoretical Ayn Rand world). It is unreasonable to hold users responsible for failure modes that are not obvious - but that the engineers of the product are aware of. There are, of course, special cases in which protecting the users from harm is nearly impossible. However, there are many cases in which a simple design element can save lives & limbs. When a company is too cheap to spend $0.14 on a deadmans switch for a large machine that requires someone to climb inside to repair - and a few people die each year because of the combined savings of $3.72 - we've got a problem. Fortunately, the courts solved that problem. Back to the original subject: a software tool that very easily fails in a way that is hazardous, when this could easily be prevented - is flawed. It isn't the 'bad workman' it's the 'bad tool'.
> Have iterations, yes, but a project can really be delayed if a project manager doesn't put manage > expectations and suggest that interface issues should be change requests after delivery as to let > users work on it for an extended period of time. By then, they will have a better idea of what they > want, and effort won't be duplicated (and triplicated). Sure - managing expectations is critical. And if the users and the project manager have a good relationship that can work. But if they don't - the users can get screwed - when the development team returns as estimate for work they don't want to do - that is rediculously high. I think one of the biggest problems here is the typical outsourcing model - which you mention earlier in your post - and that just about forces waterfall development.
GreyWolf3000 wrote: > where labor unions drive up the price of Ice Cream to 5 or 6 dollars a scoop Yep, the dps (dollar per scoop) metric has many long-overlooked benefits: 1. enables concise regional comparisons 2. identifies regions that might be controlled by them pesky commie/atheist/labor/lefty types - who, like the mafia and garbage, use their domination of ice-cream parlors in the NE to peddle their wares. Remember the Alamo!
Whoa - cool! I hadn't seen that, but will have to check it out. The standard language is a lot of big shops (including mine) is java. But java (especially j2ee) is so anti-productive that I'm always looking for excuses to use something else. My strategy lately has been to use python - since it can be evolved into jython, then eventually to java if necessary. But rexx is also a db2 procedure language (along with visual basic, java, c, c++). Netrexx should have a place next to python now - as a simple language with a seamless upgrade path.
Rexx was incredibly cool at the time: - implemented on a dozen platforms - code was multi-platform - extremely easy to use / easy to extend / easy to maintain - could run it from MVS JCL - was the macro language for ISPF I used rexx for the following: - converted hundreds of cobol programs from cobol 68 to COBOL II (required parsing code, replacing periods with end-ifs, end-searchs, etc) - created 'asserts' for several programming languages - in which a simple function key would confirm the syntax. - created 'point & click' character interfaces - in which a function key would look up whatever was at the current cursor location and open an ISPF browser window on that file. And the above code was *easy*. Today I'm writing a lot of code in ksh & python. If python wasn't around I'd probably create this code in rexx. Although it's harder to find support for than bash - it a far better language. And although perl is more powerful in some ways - it isn't the maintenance-disaster that perl is. But python is just simply too good a language. Too bad for Rexx.
A papertrail just gives a false sense of security - this is like a database transaction problem. Who says that just because you've got a paper receipt that the machine used the same electronic results? The *only* way to get around this is for the machine to produce a human-readable printout - which is then counted by a simple local mechanical machine. Then those same printouts are sent up to be counted again at the county level, then again up at the state level. This would allow anyone to easily balance the counts at the individual, preceint, county, and state level. Everything could be easily audited and any mistakes in logistics identified. Just about all other solutions I've seen require faith in some part of the system. What I'm recommending here isn't convenient, and is labor-intensive. But who cares? We're talking about voting right? So, spend a little time on it. Hell, don't the Canadians have a completely manual system?
> Well, Python is dynamically typed for one. Dynamic typing is great for scripting languages > because the language gets out of your way and the rules are laxer, so you can work quicker. It's > not so great for larger or more complex pieces of code where robustness is more important than > having fewer rules. In theory perhaps. But I'm seeing python used in larger & larger applications - and believe any problems created by dynamic typing are more than compensated for by its simplicity. > Python has a few other problems. It's (a) slow even with tools like Psyco Really? Makes you wonder about claims like - "visual basic is what really made windows a success". How could such a slow, interpreted language like vb work so well for windows - on 486-66s? > and (b) has a wierd non-C like syntax which is a bit offputting for people who are used to > C++/Java/C# style languages. any c++/java/c# programmer worth his salt should be able to pick up python almost immediately. It's simple and intuitive. And the use of whitespace to enforce nesting consistency hardly makes the syntax 'weird'.
all good points, but about as insightful as the safety stickers on ladders. And yes, I'm sure this article will be very useful to someone out there...