And the bank's response to that is, you 'gave away' your information to someone. Why if the information, which they've told you is confidential, is revealed BY YOUR FAULTY EQUIPMENT, should they be on the hook to bail you out?
It is just the same as if you magic markered your PIN onto the back of your ATM card and someone stole it and drained your account. I GUARANTEE you the bank will wash its hands of your loss. And rightly so.
There is another factor involved. If the bank has to eat the losses, then the bank will pass them on to ALL the customers. So now you're not charging 'the bank' for the loss, your charging ALL THE PEOPLE THAT DIDN'T let themselves get ripped off!
So the question becomes "Why the hell should I pay for YOUR negligence/incompetence?' Let the idiot that let someone steal his private data off his machine pay for his own mistakes!
Of course, it makes sense for both parties to deploy a technology that is as secure as possible. The bank which doesn't should be loosing business (no matter who pays for the fraud). Still, I see NO reason why the financial institution should be liable unless the loss occured because of their act of negligence. Which exactly dovetails with liability law pretty much the world over.
ROFL!
So, let me get this straight. You're PC is infected with whatever malware, or just buggy client software you happen to have installed, and via interacting with my financial application you leak information, etc and get 0wned. And you want to make ME responsible!!!!!!!????? Wow, what a fscking smart idea!
Excuse me, you missed a couple of points my friend.
1) It is your PC, you own it, you operate it, you install the software on it. What business is it of mine telling you how to manage it?
2) Even supposing I WANTED to tell you how to manage it. Lets say I provide you with a 'free auditing tool', it is STILL not my responsibility to see to it that you use it wisely.
3) Supposing some law DID make me responsible for your PC. WTF??!! How do I have any possibility of carrying out that expectation. Shall I ship you a lock box to put the machine in so its physically secure? Shall my technicians show up and install my software (AND NOTHING ELSE) on my prefered OS so I know you're secure? I'm SURE AS HELL not going to insist on ANY less than that if I'm on the hook!!!
The whole concept is preposterous on the face of it. An absurd proposition which cannot be implemented in the real world.
Now, lets be clear here, both the customer and the bank have an interest in being able to do secure business together. So as you say, picking up a $70 tab makes perfectly good sense, and maybe the cost should be split between you and the bank. But also recall, they're a business, they WILL make back that money, so basically I think it is smarter if they just say 'You need a device that complies with XYZ standard to talk to us.' And maybe ONLY THEN does the bank assume liability. Personally if I was the bank I'd still be nervous.
Yeah, banks should be, and are, on the hook for whatever happens inside the limits of their own networks, but outside of that, it is just not POSSIBLE.
I remember someone figured this out 10 or 15 years ago. It does work, and surprisingly well. But it isn't exactly news. Though it is cute that GDM can support it.
On an already ugly programming language, or at least one which is at best obsolescent from a technology perspective.
Having 25+ years of experience in the field my opinion is C++ is aweful. No amount of hacking around the edges of it is ever going to fix that. Due to the very nature of the language defect rates are exceedingly high. Even with modern development, test, and debugging tools building software in C++ is an endeavor which requires an inordinate amount of expertise, mostly in how to avoid doing most of the things the language allows you to do because 99% of them are bad ideas. Instead of learning to program well, most instruction in C++ has to be focused on how to work around its hodgepodge of misfeatures. Personally I wouldn't even consider allowing anyone with less than 5+ years of experience touch a commercial C++ application.
The whole stankin' mess should be retired. The sooner the better.
In fact there's probably some theorem which covers that, lol. Church's Law however does apply to any exclusive shared resource, so at SOME level there is a potential bottleneck, even if the critical section is one line of code. That would be the best case and then chances are the load would need to be huge.
Sure, any system can only have some maximum throughput. I think in the case I'm talking about the real observation is that updating the book data structure (RDBMS tables or whatever the concrete implementation is) is an operation which is critical and its performance dominates the performance of the overall application. I think you find a significant amount of these cases in OLTP type applications. Luckily processors are fast, so small critical sections are annoying, but you can live with them...
And now you came to the nut of the problem. Now your operations have to be reversible, and at some point the sequence dependency has to be resolved. I'd look at it this way. Your solution is virtually guaranteed to be significantly more complex, and in fact in a practical system there is already a good deal of (to the application programmer) parallel activity going on, assuming you're using good tools.
For example the search for potential matches is going to be a database table SELECT, which any good RDBMS will execute as a (at least potentially) parallel scan. However, you can't with any existing modern tools do something like have several threads submitting different orders into the algorithm in parallel because THERE IS NO WAY FOR ONE MESSAGE TO KNOW THAT OTHERS EXIST. Parse the problem. Messages arrive continuously, each one permutes the existing state of the book.
The real problem with any attempt to do all this asynchronously is practical. The incoming message rate can be almost arbitrarily high. Suppose you dispatch a thread to do the match for each incoming message. There is no knowable guarantee is to the order of execution within the set of all currently running threads. You may have to backtrack an arbitrary number of steps, N. N is simply the number of received but not yet retired messages at any given time. Also, backtracking IS very expensive in real terms, at the very least a 'delta' has to exist between before and after state for each operation so it can be reversed. Plus you have no real way of knowing when you can throw away one of those deltas because you don't know what the value of N is. It is possible 1000 messages poured in in the last 2nd and the whims of thread scheduling could mean message number 1000 hit the book first, but you don't know the value of N, so all you can essentially do is keep the data required for reversal basically forever.
Now I can sketch out in my head how in theory you could do it, but frankly the overhead of the whole thing is greater than just accepting that there is a bottleneck, reducing the critical section to the smallest extent possible, and optimizing it highly for serial execution.
I think this is in essence the nature of the problem. Certain types of things are just not naturally amenable to parallel execution BY THEIR VERY NATURE, and won't ever be. And no tool will tell you that. And any tool that lets you deal with it will still have to implicitly or explicitly deal with all of the same factors and be just as complex. Plus there is just the problem of generality. One could ask why APIs don't simply become so high level and abstract that programmers never have to deal with nuts and bolts? Nothing about the structure of existing software libraries disallows that, but the higher the level you operate at, the more problem domain specific your code has to be, or else it has to become SO generalized that you just move the problem to how to specify exactly which of the 9000 supported ways things work you actually wanted.
Its very simple, and nobody can avoid it. If you have ANY shared resource, then every process/thread/whatever (and it does not matter how you 'hide it under the hood' of your code) then you will be subject to Church's Law. Not to say we cannot or don't need something better than threads, just that as you said, there are problems that just CANNOT achieve much extra performance from parallel execution.
So we come to the question of ARCHITECTURE and design. When you have a problem like that, the only viable approach is to attempt to recast it into another problem, and that is a language/toolkit independent issue because the problem itself is not a language/toolkit/framework level issue.
The conclusion being that it is not possible to just 'abstract away' all parallelism considerations from software engineering. At best maybe some day we'll make tools so smart and so high level that THEY will deal with the problem for us. That will be nice and all, but it won't make it go away.
I can throw you the very most classic example there is. You cannot parallelize an order matching algorithm for instance. Every order has to be processed in a fixed sequence. If I have a book of bids and asks and you come in with an order, it is a REGULATORY REQUIREMENT that I have to process it in the order it came into the system. This is an absolutely serialized type of operation. I've got to check for a match on your order and either book it or execute. No ifs ands or buts. An entire order matching SYSTEM can handle multiple orders for different instruments in tandem, but any good middleware framework will abstract that level away from where you even need to know about it outside of setting some configuration on your message queues and transaction manager.
Sure, a lot of things can benefit from parallel execution, but MANY tasks inherently contain mandatorially serial sequences of operations. You can try to break them down into steps and execute different steps on different cores/threads at the same time (one can fetch a new message while another performs matching) but what you will find is that in a lot of cases the overhead of the locking, queueing, and handoff of data from one stage to the next, combined with loss of data locality and cache coherency in current systems will actually DEGRADE performance. Many times it is a matter of a trade off between throughput and latency.
At least in some application domains architecture of the data processing system at a higher level is a lot more important than cute optimizations at the code level. I think one of the reasons "younger programmers are more interested in parallel programming" is the ILLUSION created by the fact that they're the ones doing low level coding, whereas I'm up here at a higher level of design where the issue is important, but not from a coding perspective. In other words I really don't care about queues, semaphores, and spinlocks, etc. I care about data flows, scalability, throughput, reliability, and latency, which are largely NOT a coder level issue. So maybe you'd find that senior developers/system architects/analysts ARE concerned about the same issues as 'younger coders', but they see them in a different way, and may not even consider it the same thing at all.
Anyone who wants to learn about elegance in software design NEEDS to study FORTH. No program ever written by man is more elegant in design than FORTH. Not to mention it is a damned amazing programming language in its own right.
Is like the equivalent of around $50k today, easily. Fords were selling for in the $250 range IIRC... So I think it is optimistic to say it was an 'affordable' vehicle.
Basically sounds like about the equivalent of a golf cart with a big battery load. Back then something like that would have been pretty cool, and 25MPH was about top speed on the roads of that day anyhow.
It is cute, but technologically? Not that interesting, lol.
99% of the games for Linux either suck, or they're just basic 'doo-dad' type games (which are fine, but not really what we're talking about), or they're just ANCIENT.
So, basically Linux has no games worth mentioning, thus NO GAMERS RUN LINUX. Thus no game companies support Linux. Ad infinitum.
Every 3-4 years this comes up. Actually a goodly number of game companies HAVE released a Linux title or two. Obviously Id has had ports for a long time of at least their older stuff. Kohan was released for Linux, and MindWare (Something like that) had one or two games. Altogether you can count the commercial linux releases of mainstream games on one hand. It isn't going to change. The vendors couldn't move the product, and the gamers aren't going to use Linux over Windoze until the majority of titles they want are available.
Now, what likely WILL happen is game consoles, PVRs, settop boxes, and HTPCs (and home desktops) will pretty much merge into one seamless whole, and which OS do you think they'll run? You guessed it. At which time there will be plenty of 'Linux' games. Of course by then nobody will really even notice. Give it 5 years. You will probably NEVER be able to run them on your "PC" but the games will run on Linux.
I'm not exactly sure what you mean. I would hardly call J2EE a 'fad', it is a technology which has been around for about 10 years now.
And I don't think you can equate an 'Oracle database cluster' to enterprise middleware. They aren't the same thing at all. Sure, you can move a LOT of business logic into SQL stored procedures. You still need to do all sorts of other things. At the very most minimal you need external logic to accept incoming data (SOAP calls, RPC, JMS messages, whatever) and invoke the proper procedures, and probably send data/results to other apps. That code is also going to have to potentially manage transactions, etc.
Mainly this is why Oracle itself is a major J2EE application server vendor. Databases are fine, and you can do a lot with them. For some types of applications you can basically build the whole app in the database and use a mostly dumb client, but that strategy is still pretty limited.
Suppose I want to distribute my app, which implements an interface to my service? It is not a publicly available service and I don't particularly care to distribute my app to anyone under the sun. Not only that, I NEED to be in control of updates. In other words in a corporate environment there is a very legitimate need to be able to distribute a mobile application yourself, or be able to install it directly on a device from a local repository. Not only that, I'm not charging people for the APP, I'm charging them for the service (or maybe licensing them the back end software itself). Furthermore it would be ludicrous for me to now say to my client 'OK, to install this you have to go to the Apple "app store" and download it.'
I don't have a problem with the App Store itself as a concept, but it certainly isn't even close to meeting business needs, and if this is going to be the ONLY way to get an app on the iPhone, then it will not be a supported platform for a wide range of business applications.
You simply CANNOT in any sane world replicate the large scale clustering, distributed transaction management, connectors, and resource management capabilities of a good J2EE server. Furthermore you WILL need that kind of thing if you want to build a piece of software that has requirements like ABSOLUTELY no single failure under any circumstances can ever loose a transaction and you process 10k transactions per second with 5 9's reliability 24/7/365.
Yes, you can, and pretty easily, too, using Erlang. The contortions you have to go through in Java to get messaging, queuing, bus-connections, failover, clustering and all that stuff to work is ridiculous. You can spend hours declaring, configuring, creating adapters, installing drivers, extensions, hibernate properties, blah blah blah and you're not only no closer to being done, you get to write your logic in... Java!
Hmmm. In my J2EE environment all I have to do in order to set up distributed transactions is tell the container that I want distributed transactions. It involves editing one deployable XML file. So I have no clue what 'contortions' you are talking about... Same with clustering, at least on JBoss all I ever had to do was edit one or two config files and Wallah! my session state is synched across the cluster. Easy as pie. That is the whole point though, ALL you really have to worry about is business logic, everything else is handled in interceptors by the container. I wouldn't venture to comment on Erlang since I've never used it, but I'd venture to say you STILL have to have all the configuration details someplace.
Java goons can spend days talking about persistence layers and attribute storage and web service connecters to the enterprise bus. And after weeks of hobbling along and some purchases of middleware and object brokers and JMS this and that (and don't forget the servers to run it) they can start writing a bajillion classes and interfaces for every function. All this to support a messaging system with no more functionality than this:
resource ! {self(), {request, Key}
And no, that's not the abstraction or exposed interface--that's the nitty gritty detail.
Again, I can't comment on what you do and how you do it in Erlang. The sum total of all JMS related code in our LARGE trading system is 2 classes, neither of which is more than 100 lines of code at most, and 75% of that is there to allow you to run the whole system outside the container for unit testing. Again I don't know Erlang, so I can't compare, but ActiveMQ (the JMS broker we use) provides a fantastic amount of functionality which is all easily accessed out of one config file. Given the requirements of our system I think it is safe to say that no matter what platform we used some similar level of configurability would be required. And if you want to compare simple cases I can write an MDB in 10 lines of code, 6 of which are just annotations that tell the container where the message flow comes from, plus whatever business logic I want.
Java--the technology, the language, and the culture is a joke. Unfortunately, as you say, it's ever so Serious and Ready for the Enterprise--so it's not a very funny joke. When you actually get your Enterprise Solution delivered (never anything so Un-Serious and Un-Enterprise as a program in Java World), you now get to deal with upgrade and dependency headaches, schema changes and--why is my RPC performing so poorly? Marshalling overhead? How do I fix that? Throw away my objects, throw vectors of strings at it, buy faster CPUs, throw some more Tibco on it, please!
Well, I'd be interested to see what the comparison in the real world would be between the 2 platforms in our problem domain. As for the other stuff, if you have horrible problems with schema changes then you perhaps didn't follow a solid design pattern to begin with... I just added 4 columns to 2 CORE ta
Yeah, SNMP has I think kind of outlived its usefulness. We're probably stuck with it forever, but it would be really nice to have something better to replace it with. Transactions would definitely be a good feature to have, with 2 phase commit of course!
I'm also a fan of REST, or at least the general principles of REST. I'm of the opinion that HTTP's standard url style encoding of form data is a poor protocol, but essentially the concepts are good. I do use SOAP quite a bit, though I'm not really in love with it, it seems to be the only viable game in town at this point if you go beyond simple form input. Even there though you can definitely adhere to some 'restful principles'. 2-phase commit though seems to me to be kind of against the basic REST philosophy, but then again it is a necessary thing in some environments.
I inherited a C++ based trading system about 5 years ago. Millions of lines of code. Took 10 guys to code the thing and they burned through 42 million $. I and basically 2 other guys rebuilt the system on JBoss in under 2 years. The original system was actually really well designed, it ran a number of Bloomberg's fixed income applications and Brut and NYFIX/Patriot were built on the same platform, but the fact is with a totally custom designed system like that things aren't totally standard, and every time you need to do something beyond what the platform was designed for you're reinventing stuff that J2EE/EJB3 will do OOB with a few annotations or whatnot. It just doesn't make sense to reinvent that kind of stuff.
There are a lot of fairly crappy J2EE based apps out there. As I say, I think they result from A) a poor appreciation of how J2EE/EJB are best used, and B) a poor analysis (or no analysis) up front of the problem domain. Usually when you don't do really detailed analysis you end up fighting AGAINST the way J2EE wants things to work, and that never gives good results. The other thing I'd have to observe though is that EJB3 really was a huge step forward. Older versions of EJB sucked. Even now with EJB3 I still rarely use Entity Beans. I think ORM solutions are a bad idea, no matter how polished they are. Someone mentioned always having an abstraction away from the RDBMS, and I agree of course, but ORMs are not it.
There is nothing wrong with a full up J2EE environment. It simply exists for certain specific purposes. It makes no more sense to write many applications on J2EE than it does to write web sites in FORTRAN.
On the other hand, if you write serious enterprise class middleware there is nothing better and those frameworks you find 'icky' are 100% necessary. You simply CANNOT in any sane world replicate the large scale clustering, distributed transaction management, connectors, and resource management capabilities of a good J2EE server. Furthermore you WILL need that kind of thing if you want to build a piece of software that has requirements like ABSOLUTELY no single failure under any circumstances can ever loose a transaction and you process 10k transactions per second with 5 9's reliability 24/7/365.
The other problem with most developers (most teams) is they simply don't have the training in properly designing their applications for that kind of environment. You HAVE to know all the ins and outs of where your transaction boundaries are, exactly what all the possible execution paths (exceptions especially!) are, and map it all out. Anyone that tries to build complex J2EE apps by sitting down at a keyboard and pounding keys will FAIL miserably, and they will then lament about how horrible J2EE is. No, you need to know exactly what you are going to write first. THEN when you sit down and start developing all that 'J2EE cruft' actually turns out to be your friend because most of the hard stuff is already done for you.
Its all a matter of what you're problem set is, and knowing the tools well enough.
OK, in the long run, for purposes of exploration, yes perhaps a manned mission is reasonable. But in the short to mid term, it just seems pointless. There is still PLENTY of work for robots to do on Mars. Why not spend another 20 to 50 years on unmanned missions, which will naturally become ever more capable?
In the mean time the Moon is a far better target for manned operations. It has a significantly LESS hostile environment (no atmosphere makes things a lot easier, 1/100th bar of CO2 is not doing anyone any good). The risks and costs are very much smaller, and there is a huge amount of science we can do. Not only that but much of the knowledge gained in manned operations on the Moon will be generally applicable to manned operations anywhere in the Solar System, including Mars. It may actually be CHEAPER in the long run to go back to the Moon first. Not only that but there are geopolitical reasons for establishing a presence on the Moon which may well virtually mandate going to the Moon anyway, so why not do it first?
Furthermore there are, albeit tenuous, arguments for significant economic returns from Manned operations on the Moon. There are no such arguments re Mars and never will be. All a manned Mars expedition will accomplish is burning 100's of billions of $ on a program which will generate a PR event that, judging from our experiences with Apollo, will last 6 months, then the public will get bored with it, and the program will wither. No doubt some interesting science and engineering will come out of it, but it won't be worth the cost (100 billion $ easily represents 20-50 unmanned missions). Most of the same benefits in the mid to long term will also result from Lunar operations. There will be plenty of scientific benefits and the engineering knowledge gained will be essentially the same. On the other hand the risks and costs will be MUCH lower, maybe by an order of magnitude. Naturally we'll probably actually spend similar amounts on either program, but we'll get a lot more for those bucks on the Moon.
Plus, as some NASA commentators have pointed out, the hardware required to go back to the Moon will be sufficient in general for accomplishing other valuable Manned missions, such as a near-Earth asteroid mission, or any other mission we can think of involving human spaceflight in the vicinity of Earth.
Finally there is at least one direct argument for NOT setting foot on Mars. It will complicate the search for life there. No manned mission can ever be guaranteed not to result in some biological contamination of the Martian environment. Realistically it may not be much of a problem, but ANY signs of life discovered on Mars from that point forward will have to be evaluated in order to determine whether or not they resulted from contamination, however remote the possibility. Which just complicates that whole equation considerably. So it may even be inadvisable at this time to set foot on Mars.
Forget Mars. It is a 'bridge too far' at this point. Give it 50 years. Maybe by then we'll have the type of spacecraft that are required for serious manned exploration of deep space, like say nuclear fusion powered VASIMER type rockets which can ferry back and forth multiple times with very large payloads and follow fast transfer orbits when carrying human crews. At that point the costs will be reduced vastly and it will make a lot more sense to go there. In 50 years it may be cheaper to go to Mars than it is to go to the Moon now, and in the mean time we can direct our limited funds to more sensible projects.
Mars certainly is an emotionally compelling target, but it simply isn't a logical goal for manned spaceflight at this time, and logic trumps emotion. A logically sound space program is a good space program. One based on ill advised emotional arguments is not.
There is of course an alternative sort of ending to this story...
The end of Olaf Stapledon's 'Star Maker'.
Finally the Universal Mind achieves the absolute uttermost pinnacle of mental development possible within the limits of the resources available in our universe. And what does it see when it dares to contemplate what lies beyond? That it is nothing, not even the smallest grain of sand. Nothing can compare with the infinite creative force of the maker. No finite consciousness can even encompass a measurable portion of it or even make any meaningful statement about its nature.
It cost Leo Tolstoy what to write 'War and Peace'? 20 bucks worth of paper and 4 or 5 (ok 12) pens?
Even a modest video game is going to cost 5 million $, and the decent ones are 10x or more. They HAVE to have mass market appeal. There will never be much in the way of really high quality games that aren't 'pop culture'. At least not until one person can make them single handed, or with a couple of people and a really small budget (like indy films).
How about this for a 'knowledge representation system'. Forget about WHERE stuff is, it just doesn't matter. A URL all you need. Granted stuff can move or vanish, but there is just no reason why on earth there has to be ONE GIANT COMPENDIUM which is stored in one place. In fact the whole idea is bad, and ultimately cuts against the underlying concept of the web and the Internet itself.
Secondly, there is NO problem with 'spammed ratings' say for articles, IF the ratings system is not just some simplistic dumb thing (kinda like what/. has, but hehe maybe that's for another day...). Instead what we need is a way to signify a 'level of trust' we have in the people who are MAKING the ratings. If I think Anne Coulter is a complete ass, then I could give a rat's behind what ratings she gives things. So all I have to know is WHO rated what, and filter the ratings, and come up with my own rating. MOST of that can ultimately be automated. If I know person's X,Y, and Z usually agree with me, then I can trust their ratings, and their meta-ratings (ratings of ratings). Systems to identify clusters of people with similar views on things is highly feasible, so 95% of this work can go on behind the scenes.
Now, ALL of this infrastructure can exist distributed all over the net. Anyone can run algorithms to go look at ratings data and crunch it up any which way to midnight and give me an index I like. I can pick and choose as I please.
Race to the bottom? Where are this corporations going to get workers? Many people can move to someplace else. For those who can't afford it when Corporation Y moves into an area Corporation X will have competition for employees and therefore will pay more. Both Honda and Toyota have opened new factories in the US and are beating Detroit's big three. The jobs created pay better than the jobs the area already had.
Uh, have you ANY knowledge of the history of labor relations? US wages have declined steadily for the last 35 years.
So then the voters need to hold their government responsible. Oh, and I'll add that because pollution crosses manmade lines on paper, or a monitor, the environment is one area the feds should be able to set minimum standards. Actually here I'd prefer something international.
And so we agree:) Some considerations are of national, or as you point out transnational, importance, and thus logically the perview of the Federal Government
No, it would cost powerful corporations more to bribe local officials, who are directly responsible to local voters, than it costs to bribe federal officials. As Walmart is finding out local opposition is getting stronger. At the federal level there's not much that can be done but at the local level people have more power.
Nonsense. All you have to do is look at what has actually happened with WalMart. They've run roughshod over state and local governments all over the country. Out of every, what, 1000 stores or so they've built they've run into trouble in one place? I really seriously doubt WalMart management is loosing a lot of sleep about it. No, instead they're raking in billions of $ while Medicaide or other programs pay their workers health care costs and they aren't even putting into the till for their share of that. Trust me, I know from personal experience about the way they operate, no local govt/planning organization has a snowball's chance in hell of doing more than slowing them down a bit. They get absolutely whatever they want at a local level. For every $ we can spend they have 100, and they're perfectly willing to ram their development plans down the town's throats.
While we ALL like the theory of 'small government', the reality is we live in the 21st century, not the 18th century, and pretending we can go back to an 18th century model of government is just that, pretending.
No it not, it's trying to do something. Those like you, from what you say (pretending), would have people roll over. As the old saying goes, all that's required for evil to triumph is for good men to do nothing.
Well, you can define what I do as 'nothing' if it makes you feel better. Doing nothing is often better than doing something that makes things worse in any case. In any case you sound like you've swallowed the whole 'there is an evil liberal agenda to have all powerful government'. It is crap. It is Corporatist propaganda. The sad part is just how utterly gullible such a large segment of the population is. Who do you think is standing in the background with glee in their eyes just hoping for more 'deregulation' and tax cuts for the rich?
No, the fact is nobody is in favor of excessive government or wasteful spending. What reasonable person would be for that? Give people a little credit. Reasonable people can disagree, and in the long run reasonable compromises usually prevail. I'd also observe that while the Republicans have given loads of lip service to shrinking government, they've failed utterly to live up to their word. All I've seen is a load of corporate welfare plans and tax cuts for the rich.
Please show examples of this to support your contention Ron Paul's voting record does not match his beliefs.
The problem with the 'let the states do it' concept is that the states end up in a 'race to the bottom'. Politicians go grubbing for tax revenue and what happens? Corporation X, Y, and Z come along and say 'well, if you just gut your environmental laws, and forgive 90% of our taxes, and gift us with 40 million bucks to boot, maybe we'll build a factory in your state.' The politicians in most states simply cannot go up against that. The big corps are NOT OUR FRIENDS, we are just 2-legged sacks of money to them. They don't give a rat's ass about anything but short-term profits. That is how they are SUPPOSED to be, we set it up that way. They WILL rape the environment and screw the common man. Uncle SAM is big enough and the US (even now) is too big a market collectively to be entirely powerless against that. Even so you see what kind of govt we have now? Put it all on the states, it will be 10x worse.
While we ALL like the theory of 'small government', the reality is we live in the 21st century, not the 18th century, and pretending we can go back to an 18th century model of government is just that, pretending. It won't work, it would be a giant disaster if we were stupid enough to try it, and it just isn't going to happen. Which is why Ron Paul and snowballs in hell are good companions in the same sentence.
I would like to say I admire the guy for his stand, but A) the Republican Party is a bunch of filthy criminals, so standing with them is unconscionable. B) Paul likes to say his voting record is consistent with his beliefs, but it isn't entirely so. If you look close you can see the spin. Maybe it is a good bit less ridiculous than most politicians but ALL politicians do it.
If you don't have a solution in mind and ready to try out, you ain't got much.
Of course you have to sell management and staff on it, but THEY don't know what the best solutions are. So the reasonable answer is, talk to some of them, show them a Wiki, explain to them how it might work. Now you may end up with a somewhat different solution than you originally thought. You have to be flexible and it is quite likely other people's ideas are going to improve on yours.
But if you go into it with no proposal at all in mind things are going to be all over the map.
This is part and parcel of the common misconception that IT solutions in general should start out with a top down problem analysis. It is a nice theory, but it doesn't work well in the real world. The magic is really having someone who is both technically savvy (they don't have to be a tech guru, just well aware of the available solutions and what types of problems they best address) and also skilled at both listening to what other people want and what their ideas are, and synthesizing and articulating a coherent vision from that. AND you gotta be organized enough to manage pulling it off, etc. Ever wondered why the percentage of IT projects that succeed is small? Now you know, it often requires a pretty rare skill set to pull it off. Of course the better overall your organization is at putting together the right people to do that magic, the more things they'll succeed at. Regardless of anything else you have in terms of strengths and weaknesses, the one I think is really key is to be able to listen, and be flexible enough to accept what you hear and act on it.
Slashdot Mirror
And the bank's response to that is, you 'gave away' your information to someone. Why if the information, which they've told you is confidential, is revealed BY YOUR FAULTY EQUIPMENT, should they be on the hook to bail you out?
It is just the same as if you magic markered your PIN onto the back of your ATM card and someone stole it and drained your account. I GUARANTEE you the bank will wash its hands of your loss. And rightly so.
There is another factor involved. If the bank has to eat the losses, then the bank will pass them on to ALL the customers. So now you're not charging 'the bank' for the loss, your charging ALL THE PEOPLE THAT DIDN'T let themselves get ripped off!
So the question becomes "Why the hell should I pay for YOUR negligence/incompetence?' Let the idiot that let someone steal his private data off his machine pay for his own mistakes!
Of course, it makes sense for both parties to deploy a technology that is as secure as possible. The bank which doesn't should be loosing business (no matter who pays for the fraud). Still, I see NO reason why the financial institution should be liable unless the loss occured because of their act of negligence. Which exactly dovetails with liability law pretty much the world over.
ROFL! So, let me get this straight. You're PC is infected with whatever malware, or just buggy client software you happen to have installed, and via interacting with my financial application you leak information, etc and get 0wned. And you want to make ME responsible!!!!!!!????? Wow, what a fscking smart idea! Excuse me, you missed a couple of points my friend. 1) It is your PC, you own it, you operate it, you install the software on it. What business is it of mine telling you how to manage it? 2) Even supposing I WANTED to tell you how to manage it. Lets say I provide you with a 'free auditing tool', it is STILL not my responsibility to see to it that you use it wisely. 3) Supposing some law DID make me responsible for your PC. WTF??!! How do I have any possibility of carrying out that expectation. Shall I ship you a lock box to put the machine in so its physically secure? Shall my technicians show up and install my software (AND NOTHING ELSE) on my prefered OS so I know you're secure? I'm SURE AS HELL not going to insist on ANY less than that if I'm on the hook!!! The whole concept is preposterous on the face of it. An absurd proposition which cannot be implemented in the real world. Now, lets be clear here, both the customer and the bank have an interest in being able to do secure business together. So as you say, picking up a $70 tab makes perfectly good sense, and maybe the cost should be split between you and the bank. But also recall, they're a business, they WILL make back that money, so basically I think it is smarter if they just say 'You need a device that complies with XYZ standard to talk to us.' And maybe ONLY THEN does the bank assume liability. Personally if I was the bank I'd still be nervous. Yeah, banks should be, and are, on the hook for whatever happens inside the limits of their own networks, but outside of that, it is just not POSSIBLE.
I remember someone figured this out 10 or 15 years ago. It does work, and surprisingly well. But it isn't exactly news. Though it is cute that GDM can support it.
On an already ugly programming language, or at least one which is at best obsolescent from a technology perspective.
Having 25+ years of experience in the field my opinion is C++ is aweful. No amount of hacking around the edges of it is ever going to fix that. Due to the very nature of the language defect rates are exceedingly high. Even with modern development, test, and debugging tools building software in C++ is an endeavor which requires an inordinate amount of expertise, mostly in how to avoid doing most of the things the language allows you to do because 99% of them are bad ideas. Instead of learning to program well, most instruction in C++ has to be focused on how to work around its hodgepodge of misfeatures. Personally I wouldn't even consider allowing anyone with less than 5+ years of experience touch a commercial C++ application.
The whole stankin' mess should be retired. The sooner the better.
That doesn't use 200mb of RAM and does a good job displaying web pages?
Time to move on...
In fact there's probably some theorem which covers that, lol. Church's Law however does apply to any exclusive shared resource, so at SOME level there is a potential bottleneck, even if the critical section is one line of code. That would be the best case and then chances are the load would need to be huge.
Sure, any system can only have some maximum throughput. I think in the case I'm talking about the real observation is that updating the book data structure (RDBMS tables or whatever the concrete implementation is) is an operation which is critical and its performance dominates the performance of the overall application. I think you find a significant amount of these cases in OLTP type applications. Luckily processors are fast, so small critical sections are annoying, but you can live with them...
And now you came to the nut of the problem. Now your operations have to be reversible, and at some point the sequence dependency has to be resolved. I'd look at it this way. Your solution is virtually guaranteed to be significantly more complex, and in fact in a practical system there is already a good deal of (to the application programmer) parallel activity going on, assuming you're using good tools.
For example the search for potential matches is going to be a database table SELECT, which any good RDBMS will execute as a (at least potentially) parallel scan. However, you can't with any existing modern tools do something like have several threads submitting different orders into the algorithm in parallel because THERE IS NO WAY FOR ONE MESSAGE TO KNOW THAT OTHERS EXIST. Parse the problem. Messages arrive continuously, each one permutes the existing state of the book.
The real problem with any attempt to do all this asynchronously is practical. The incoming message rate can be almost arbitrarily high. Suppose you dispatch a thread to do the match for each incoming message. There is no knowable guarantee is to the order of execution within the set of all currently running threads. You may have to backtrack an arbitrary number of steps, N. N is simply the number of received but not yet retired messages at any given time. Also, backtracking IS very expensive in real terms, at the very least a 'delta' has to exist between before and after state for each operation so it can be reversed. Plus you have no real way of knowing when you can throw away one of those deltas because you don't know what the value of N is. It is possible 1000 messages poured in in the last 2nd and the whims of thread scheduling could mean message number 1000 hit the book first, but you don't know the value of N, so all you can essentially do is keep the data required for reversal basically forever.
Now I can sketch out in my head how in theory you could do it, but frankly the overhead of the whole thing is greater than just accepting that there is a bottleneck, reducing the critical section to the smallest extent possible, and optimizing it highly for serial execution.
I think this is in essence the nature of the problem. Certain types of things are just not naturally amenable to parallel execution BY THEIR VERY NATURE, and won't ever be. And no tool will tell you that. And any tool that lets you deal with it will still have to implicitly or explicitly deal with all of the same factors and be just as complex. Plus there is just the problem of generality. One could ask why APIs don't simply become so high level and abstract that programmers never have to deal with nuts and bolts? Nothing about the structure of existing software libraries disallows that, but the higher the level you operate at, the more problem domain specific your code has to be, or else it has to become SO generalized that you just move the problem to how to specify exactly which of the 9000 supported ways things work you actually wanted.
Its very simple, and nobody can avoid it. If you have ANY shared resource, then every process/thread/whatever (and it does not matter how you 'hide it under the hood' of your code) then you will be subject to Church's Law. Not to say we cannot or don't need something better than threads, just that as you said, there are problems that just CANNOT achieve much extra performance from parallel execution.
So we come to the question of ARCHITECTURE and design. When you have a problem like that, the only viable approach is to attempt to recast it into another problem, and that is a language/toolkit independent issue because the problem itself is not a language/toolkit/framework level issue.
The conclusion being that it is not possible to just 'abstract away' all parallelism considerations from software engineering. At best maybe some day we'll make tools so smart and so high level that THEY will deal with the problem for us. That will be nice and all, but it won't make it go away.
I can throw you the very most classic example there is. You cannot parallelize an order matching algorithm for instance. Every order has to be processed in a fixed sequence. If I have a book of bids and asks and you come in with an order, it is a REGULATORY REQUIREMENT that I have to process it in the order it came into the system. This is an absolutely serialized type of operation. I've got to check for a match on your order and either book it or execute. No ifs ands or buts. An entire order matching SYSTEM can handle multiple orders for different instruments in tandem, but any good middleware framework will abstract that level away from where you even need to know about it outside of setting some configuration on your message queues and transaction manager.
Sure, a lot of things can benefit from parallel execution, but MANY tasks inherently contain mandatorially serial sequences of operations. You can try to break them down into steps and execute different steps on different cores/threads at the same time (one can fetch a new message while another performs matching) but what you will find is that in a lot of cases the overhead of the locking, queueing, and handoff of data from one stage to the next, combined with loss of data locality and cache coherency in current systems will actually DEGRADE performance. Many times it is a matter of a trade off between throughput and latency.
At least in some application domains architecture of the data processing system at a higher level is a lot more important than cute optimizations at the code level. I think one of the reasons "younger programmers are more interested in parallel programming" is the ILLUSION created by the fact that they're the ones doing low level coding, whereas I'm up here at a higher level of design where the issue is important, but not from a coding perspective. In other words I really don't care about queues, semaphores, and spinlocks, etc. I care about data flows, scalability, throughput, reliability, and latency, which are largely NOT a coder level issue. So maybe you'd find that senior developers/system architects/analysts ARE concerned about the same issues as 'younger coders', but they see them in a different way, and may not even consider it the same thing at all.
Anyone who wants to learn about elegance in software design NEEDS to study FORTH. No program ever written by man is more elegant in design than FORTH. Not to mention it is a damned amazing programming language in its own right.
Is like the equivalent of around $50k today, easily. Fords were selling for in the $250 range IIRC... So I think it is optimistic to say it was an 'affordable' vehicle.
Basically sounds like about the equivalent of a golf cart with a big battery load. Back then something like that would have been pretty cool, and 25MPH was about top speed on the roads of that day anyhow.
It is cute, but technologically? Not that interesting, lol.
99% of the games for Linux either suck, or they're just basic 'doo-dad' type games (which are fine, but not really what we're talking about), or they're just ANCIENT.
So, basically Linux has no games worth mentioning, thus NO GAMERS RUN LINUX. Thus no game companies support Linux. Ad infinitum.
Every 3-4 years this comes up. Actually a goodly number of game companies HAVE released a Linux title or two. Obviously Id has had ports for a long time of at least their older stuff. Kohan was released for Linux, and MindWare (Something like that) had one or two games. Altogether you can count the commercial linux releases of mainstream games on one hand. It isn't going to change. The vendors couldn't move the product, and the gamers aren't going to use Linux over Windoze until the majority of titles they want are available.
Now, what likely WILL happen is game consoles, PVRs, settop boxes, and HTPCs (and home desktops) will pretty much merge into one seamless whole, and which OS do you think they'll run? You guessed it. At which time there will be plenty of 'Linux' games. Of course by then nobody will really even notice. Give it 5 years. You will probably NEVER be able to run them on your "PC" but the games will run on Linux.
I'm not exactly sure what you mean. I would hardly call J2EE a 'fad', it is a technology which has been around for about 10 years now.
And I don't think you can equate an 'Oracle database cluster' to enterprise middleware. They aren't the same thing at all. Sure, you can move a LOT of business logic into SQL stored procedures. You still need to do all sorts of other things. At the very most minimal you need external logic to accept incoming data (SOAP calls, RPC, JMS messages, whatever) and invoke the proper procedures, and probably send data/results to other apps. That code is also going to have to potentially manage transactions, etc.
Mainly this is why Oracle itself is a major J2EE application server vendor. Databases are fine, and you can do a lot with them. For some types of applications you can basically build the whole app in the database and use a mostly dumb client, but that strategy is still pretty limited.
Suppose I want to distribute my app, which implements an interface to my service? It is not a publicly available service and I don't particularly care to distribute my app to anyone under the sun. Not only that, I NEED to be in control of updates. In other words in a corporate environment there is a very legitimate need to be able to distribute a mobile application yourself, or be able to install it directly on a device from a local repository. Not only that, I'm not charging people for the APP, I'm charging them for the service (or maybe licensing them the back end software itself). Furthermore it would be ludicrous for me to now say to my client 'OK, to install this you have to go to the Apple "app store" and download it.'
I don't have a problem with the App Store itself as a concept, but it certainly isn't even close to meeting business needs, and if this is going to be the ONLY way to get an app on the iPhone, then it will not be a supported platform for a wide range of business applications.
Yes, you can, and pretty easily, too, using Erlang. The contortions you have to go through in Java to get messaging, queuing, bus-connections, failover, clustering and all that stuff to work is ridiculous. You can spend hours declaring, configuring, creating adapters, installing drivers, extensions, hibernate properties, blah blah blah and you're not only no closer to being done, you get to write your logic in... Java!
Hmmm. In my J2EE environment all I have to do in order to set up distributed transactions is tell the container that I want distributed transactions. It involves editing one deployable XML file. So I have no clue what 'contortions' you are talking about... Same with clustering, at least on JBoss all I ever had to do was edit one or two config files and Wallah! my session state is synched across the cluster. Easy as pie. That is the whole point though, ALL you really have to worry about is business logic, everything else is handled in interceptors by the container. I wouldn't venture to comment on Erlang since I've never used it, but I'd venture to say you STILL have to have all the configuration details someplace.
Java goons can spend days talking about persistence layers and attribute storage and web service connecters to the enterprise bus. And after weeks of hobbling along and some purchases of middleware and object brokers and JMS this and that (and don't forget the servers to run it) they can start writing a bajillion classes and interfaces for every function. All this to support a messaging system with no more functionality than this:
resource ! {self(), {request, Key}
And no, that's not the abstraction or exposed interface--that's the nitty gritty detail.
Again, I can't comment on what you do and how you do it in Erlang. The sum total of all JMS related code in our LARGE trading system is 2 classes, neither of which is more than 100 lines of code at most, and 75% of that is there to allow you to run the whole system outside the container for unit testing. Again I don't know Erlang, so I can't compare, but ActiveMQ (the JMS broker we use) provides a fantastic amount of functionality which is all easily accessed out of one config file. Given the requirements of our system I think it is safe to say that no matter what platform we used some similar level of configurability would be required. And if you want to compare simple cases I can write an MDB in 10 lines of code, 6 of which are just annotations that tell the container where the message flow comes from, plus whatever business logic I want.
Java--the technology, the language, and the culture is a joke. Unfortunately, as you say, it's ever so Serious and Ready for the Enterprise--so it's not a very funny joke. When you actually get your Enterprise Solution delivered (never anything so Un-Serious and Un-Enterprise as a program in Java World), you now get to deal with upgrade and dependency headaches, schema changes and--why is my RPC performing so poorly? Marshalling overhead? How do I fix that? Throw away my objects, throw vectors of strings at it, buy faster CPUs, throw some more Tibco on it, please!
Well, I'd be interested to see what the comparison in the real world would be between the 2 platforms in our problem domain. As for the other stuff, if you have horrible problems with schema changes then you perhaps didn't follow a solid design pattern to begin with... I just added 4 columns to 2 CORE ta
Yeah, SNMP has I think kind of outlived its usefulness. We're probably stuck with it forever, but it would be really nice to have something better to replace it with. Transactions would definitely be a good feature to have, with 2 phase commit of course!
I'm also a fan of REST, or at least the general principles of REST. I'm of the opinion that HTTP's standard url style encoding of form data is a poor protocol, but essentially the concepts are good. I do use SOAP quite a bit, though I'm not really in love with it, it seems to be the only viable game in town at this point if you go beyond simple form input. Even there though you can definitely adhere to some 'restful principles'. 2-phase commit though seems to me to be kind of against the basic REST philosophy, but then again it is a necessary thing in some environments.
I inherited a C++ based trading system about 5 years ago. Millions of lines of code. Took 10 guys to code the thing and they burned through 42 million $. I and basically 2 other guys rebuilt the system on JBoss in under 2 years. The original system was actually really well designed, it ran a number of Bloomberg's fixed income applications and Brut and NYFIX/Patriot were built on the same platform, but the fact is with a totally custom designed system like that things aren't totally standard, and every time you need to do something beyond what the platform was designed for you're reinventing stuff that J2EE/EJB3 will do OOB with a few annotations or whatnot. It just doesn't make sense to reinvent that kind of stuff.
There are a lot of fairly crappy J2EE based apps out there. As I say, I think they result from A) a poor appreciation of how J2EE/EJB are best used, and B) a poor analysis (or no analysis) up front of the problem domain. Usually when you don't do really detailed analysis you end up fighting AGAINST the way J2EE wants things to work, and that never gives good results. The other thing I'd have to observe though is that EJB3 really was a huge step forward. Older versions of EJB sucked. Even now with EJB3 I still rarely use Entity Beans. I think ORM solutions are a bad idea, no matter how polished they are. Someone mentioned always having an abstraction away from the RDBMS, and I agree of course, but ORMs are not it.
There is nothing wrong with a full up J2EE environment. It simply exists for certain specific purposes. It makes no more sense to write many applications on J2EE than it does to write web sites in FORTRAN.
On the other hand, if you write serious enterprise class middleware there is nothing better and those frameworks you find 'icky' are 100% necessary. You simply CANNOT in any sane world replicate the large scale clustering, distributed transaction management, connectors, and resource management capabilities of a good J2EE server. Furthermore you WILL need that kind of thing if you want to build a piece of software that has requirements like ABSOLUTELY no single failure under any circumstances can ever loose a transaction and you process 10k transactions per second with 5 9's reliability 24/7/365.
The other problem with most developers (most teams) is they simply don't have the training in properly designing their applications for that kind of environment. You HAVE to know all the ins and outs of where your transaction boundaries are, exactly what all the possible execution paths (exceptions especially!) are, and map it all out. Anyone that tries to build complex J2EE apps by sitting down at a keyboard and pounding keys will FAIL miserably, and they will then lament about how horrible J2EE is. No, you need to know exactly what you are going to write first. THEN when you sit down and start developing all that 'J2EE cruft' actually turns out to be your friend because most of the hard stuff is already done for you.
Its all a matter of what you're problem set is, and knowing the tools well enough.
OK, in the long run, for purposes of exploration, yes perhaps a manned mission is reasonable. But in the short to mid term, it just seems pointless. There is still PLENTY of work for robots to do on Mars. Why not spend another 20 to 50 years on unmanned missions, which will naturally become ever more capable?
In the mean time the Moon is a far better target for manned operations. It has a significantly LESS hostile environment (no atmosphere makes things a lot easier, 1/100th bar of CO2 is not doing anyone any good). The risks and costs are very much smaller, and there is a huge amount of science we can do. Not only that but much of the knowledge gained in manned operations on the Moon will be generally applicable to manned operations anywhere in the Solar System, including Mars. It may actually be CHEAPER in the long run to go back to the Moon first. Not only that but there are geopolitical reasons for establishing a presence on the Moon which may well virtually mandate going to the Moon anyway, so why not do it first?
Furthermore there are, albeit tenuous, arguments for significant economic returns from Manned operations on the Moon. There are no such arguments re Mars and never will be. All a manned Mars expedition will accomplish is burning 100's of billions of $ on a program which will generate a PR event that, judging from our experiences with Apollo, will last 6 months, then the public will get bored with it, and the program will wither. No doubt some interesting science and engineering will come out of it, but it won't be worth the cost (100 billion $ easily represents 20-50 unmanned missions). Most of the same benefits in the mid to long term will also result from Lunar operations. There will be plenty of scientific benefits and the engineering knowledge gained will be essentially the same. On the other hand the risks and costs will be MUCH lower, maybe by an order of magnitude. Naturally we'll probably actually spend similar amounts on either program, but we'll get a lot more for those bucks on the Moon.
Plus, as some NASA commentators have pointed out, the hardware required to go back to the Moon will be sufficient in general for accomplishing other valuable Manned missions, such as a near-Earth asteroid mission, or any other mission we can think of involving human spaceflight in the vicinity of Earth.
Finally there is at least one direct argument for NOT setting foot on Mars. It will complicate the search for life there. No manned mission can ever be guaranteed not to result in some biological contamination of the Martian environment. Realistically it may not be much of a problem, but ANY signs of life discovered on Mars from that point forward will have to be evaluated in order to determine whether or not they resulted from contamination, however remote the possibility. Which just complicates that whole equation considerably. So it may even be inadvisable at this time to set foot on Mars.
Forget Mars. It is a 'bridge too far' at this point. Give it 50 years. Maybe by then we'll have the type of spacecraft that are required for serious manned exploration of deep space, like say nuclear fusion powered VASIMER type rockets which can ferry back and forth multiple times with very large payloads and follow fast transfer orbits when carrying human crews. At that point the costs will be reduced vastly and it will make a lot more sense to go there. In 50 years it may be cheaper to go to Mars than it is to go to the Moon now, and in the mean time we can direct our limited funds to more sensible projects.
Mars certainly is an emotionally compelling target, but it simply isn't a logical goal for manned spaceflight at this time, and logic trumps emotion. A logically sound space program is a good space program. One based on ill advised emotional arguments is not.
Hmmmm.
There is of course an alternative sort of ending to this story...
The end of Olaf Stapledon's 'Star Maker'.
Finally the Universal Mind achieves the absolute uttermost pinnacle of mental development possible within the limits of the resources available in our universe. And what does it see when it dares to contemplate what lies beyond? That it is nothing, not even the smallest grain of sand. Nothing can compare with the infinite creative force of the maker. No finite consciousness can even encompass a measurable portion of it or even make any meaningful statement about its nature.
It cost Leo Tolstoy what to write 'War and Peace'? 20 bucks worth of paper and 4 or 5 (ok 12) pens?
Even a modest video game is going to cost 5 million $, and the decent ones are 10x or more. They HAVE to have mass market appeal. There will never be much in the way of really high quality games that aren't 'pop culture'. At least not until one person can make them single handed, or with a couple of people and a really small budget (like indy films).
Yep, gotta agree with you completely on that one.
/. has, but hehe maybe that's for another day...). Instead what we need is a way to signify a 'level of trust' we have in the people who are MAKING the ratings. If I think Anne Coulter is a complete ass, then I could give a rat's behind what ratings she gives things. So all I have to know is WHO rated what, and filter the ratings, and come up with my own rating. MOST of that can ultimately be automated. If I know person's X,Y, and Z usually agree with me, then I can trust their ratings, and their meta-ratings (ratings of ratings). Systems to identify clusters of people with similar views on things is highly feasible, so 95% of this work can go on behind the scenes.
How about this for a 'knowledge representation system'. Forget about WHERE stuff is, it just doesn't matter. A URL all you need. Granted stuff can move or vanish, but there is just no reason why on earth there has to be ONE GIANT COMPENDIUM which is stored in one place. In fact the whole idea is bad, and ultimately cuts against the underlying concept of the web and the Internet itself.
Secondly, there is NO problem with 'spammed ratings' say for articles, IF the ratings system is not just some simplistic dumb thing (kinda like what
Now, ALL of this infrastructure can exist distributed all over the net. Anyone can run algorithms to go look at ratings data and crunch it up any which way to midnight and give me an index I like. I can pick and choose as I please.
Race to the bottom? Where are this corporations going to get workers? Many people can move to someplace else. For those who can't afford it when Corporation Y moves into an area Corporation X will have competition for employees and therefore will pay more. Both Honda and Toyota have opened new factories in the US and are beating Detroit's big three. The jobs created pay better than the jobs the area already had.
Uh, have you ANY knowledge of the history of labor relations? US wages have declined steadily for the last 35 years.
So then the voters need to hold their government responsible. Oh, and I'll add that because pollution crosses manmade lines on paper, or a monitor, the environment is one area the feds should be able to set minimum standards. Actually here I'd prefer something international.
And so we agree :) Some considerations are of national, or as you point out transnational, importance, and thus logically the perview of the Federal Government
No, it would cost powerful corporations more to bribe local officials, who are directly responsible to local voters, than it costs to bribe federal officials. As Walmart is finding out local opposition is getting stronger. At the federal level there's not much that can be done but at the local level people have more power.
Nonsense. All you have to do is look at what has actually happened with WalMart. They've run roughshod over state and local governments all over the country. Out of every, what, 1000 stores or so they've built they've run into trouble in one place? I really seriously doubt WalMart management is loosing a lot of sleep about it. No, instead they're raking in billions of $ while Medicaide or other programs pay their workers health care costs and they aren't even putting into the till for their share of that. Trust me, I know from personal experience about the way they operate, no local govt/planning organization has a snowball's chance in hell of doing more than slowing them down a bit. They get absolutely whatever they want at a local level. For every $ we can spend they have 100, and they're perfectly willing to ram their development plans down the town's throats.
While we ALL like the theory of 'small government', the reality is we live in the 21st century, not the 18th century, and pretending we can go back to an 18th century model of government is just that, pretending.
No it not, it's trying to do something. Those like you, from what you say (pretending), would have people roll over. As the old saying goes, all that's required for evil to triumph is for good men to do nothing.
Well, you can define what I do as 'nothing' if it makes you feel better. Doing nothing is often better than doing something that makes things worse in any case. In any case you sound like you've swallowed the whole 'there is an evil liberal agenda to have all powerful government'. It is crap. It is Corporatist propaganda. The sad part is just how utterly gullible such a large segment of the population is. Who do you think is standing in the background with glee in their eyes just hoping for more 'deregulation' and tax cuts for the rich?
No, the fact is nobody is in favor of excessive government or wasteful spending. What reasonable person would be for that? Give people a little credit. Reasonable people can disagree, and in the long run reasonable compromises usually prevail. I'd also observe that while the Republicans have given loads of lip service to shrinking government, they've failed utterly to live up to their word. All I've seen is a load of corporate welfare plans and tax cuts for the rich.
Please show examples of this to support your contention Ron Paul's voting record does not match his beliefs.
The problem with the 'let the states do it' concept is that the states end up in a 'race to the bottom'. Politicians go grubbing for tax revenue and what happens? Corporation X, Y, and Z come along and say 'well, if you just gut your environmental laws, and forgive 90% of our taxes, and gift us with 40 million bucks to boot, maybe we'll build a factory in your state.' The politicians in most states simply cannot go up against that. The big corps are NOT OUR FRIENDS, we are just 2-legged sacks of money to them. They don't give a rat's ass about anything but short-term profits. That is how they are SUPPOSED to be, we set it up that way. They WILL rape the environment and screw the common man. Uncle SAM is big enough and the US (even now) is too big a market collectively to be entirely powerless against that. Even so you see what kind of govt we have now? Put it all on the states, it will be 10x worse. While we ALL like the theory of 'small government', the reality is we live in the 21st century, not the 18th century, and pretending we can go back to an 18th century model of government is just that, pretending. It won't work, it would be a giant disaster if we were stupid enough to try it, and it just isn't going to happen. Which is why Ron Paul and snowballs in hell are good companions in the same sentence. I would like to say I admire the guy for his stand, but A) the Republican Party is a bunch of filthy criminals, so standing with them is unconscionable. B) Paul likes to say his voting record is consistent with his beliefs, but it isn't entirely so. If you look close you can see the spin. Maybe it is a good bit less ridiculous than most politicians but ALL politicians do it.
If you don't have a solution in mind and ready to try out, you ain't got much. Of course you have to sell management and staff on it, but THEY don't know what the best solutions are. So the reasonable answer is, talk to some of them, show them a Wiki, explain to them how it might work. Now you may end up with a somewhat different solution than you originally thought. You have to be flexible and it is quite likely other people's ideas are going to improve on yours. But if you go into it with no proposal at all in mind things are going to be all over the map. This is part and parcel of the common misconception that IT solutions in general should start out with a top down problem analysis. It is a nice theory, but it doesn't work well in the real world. The magic is really having someone who is both technically savvy (they don't have to be a tech guru, just well aware of the available solutions and what types of problems they best address) and also skilled at both listening to what other people want and what their ideas are, and synthesizing and articulating a coherent vision from that. AND you gotta be organized enough to manage pulling it off, etc. Ever wondered why the percentage of IT projects that succeed is small? Now you know, it often requires a pretty rare skill set to pull it off. Of course the better overall your organization is at putting together the right people to do that magic, the more things they'll succeed at. Regardless of anything else you have in terms of strengths and weaknesses, the one I think is really key is to be able to listen, and be flexible enough to accept what you hear and act on it.