Makes sense. The only people who should be allowed access to "root" are those who won't use it unless it is unavoidable.
I do like the idea of doing more stuff at the State level, and a century ago much of that would have been done at the State level. So I'm all for moving in that direction.
But this discussion is about financing, and isn't this proposal just shifting the burden of paying for them from one layer of Government to another? That isn't really a savings, which is most likely Ron Paul's objective. Since most States already have balanced budget requirements, that would be good for the long term. But don't just dump it in the lap of the States as part of some knee-jerk reaction. A budgetary shell game is not in the best interests of the Nation, and since most States are broke right now, robbing Peter to pay Paul ain't going to work.
BTW: I'm just focusing on the funding issue. I know that this is actually more complicated than just funding.
No its not. People stumble on to the right thing all the time without knowing why its right. Doing the right thing for the wrong reason is so common that it even has its own expression. So it is possible for a solid analysis to lead to a poor solution, and it is possible to stumble onto a correct solution with a bad analysis of the problem. They are unrelated.
In this case Marx identified some problems associated with Capitalism and proposed a possible solution. Other people have shot down various parts of his proposal. So the credit that Marx is due is not "finding the correct solution", but for identifying a problem, and starting the discussion on how to fix it. Since we're still talking about him well over a century later, it seems that some of his ideas have resonated with a large number of people. That alone is pretty impressive.
My personal observation was that when I got my BS way back in 1990, I knew everything that I needed to succeed in the software world except for handling non-sunny day cases. Sure, we talked about stuff like error handling, validating user input, and so forth in various classes, but it didn't really sink in. It wasn't until I had a job and worked on a system that had to stay up and run for months at a time that I learned those lessons. Most school projects only last one semester, and really only have to work once, so no one really gets much exposure to the necessity of bullet proof code.
Those scientists seem to have the same mind set. It works in a few sunny day cases, so it must be ready to ship. Management can think like that too, especially if some other group is tasked with support and bug fixes. But those of who have had to pick up the pieces know better than that. Isn't that part of the value-add that profession software people add to a project? Coding really isn't that hard to anyone who can handle the symbolic manipulation (mostly algebra) and can pay attention to details. But there is a world of difference between toys and serious applications.
As a software engineer, if you find yourself in that situation, your road is simple: look at the source, find a few corner cases that will break it, and then you can demonstrate that the code is not production ready. Then you should be able to get the green light to harden it. If you do it right, you can earn the respect of whomever cobbled together the original code, and then you can work with them next time. That is kinda the Holy Grail, isn't? You get to add your software experience and they get to add their domain knowledge.
And if they are jerks about it, at least you get to rub it in their faces how bad they are at writing code. While that isn't really a "win" of any sort, it can be amusing to knock someone down who has put himself on a pedestal that he hasn't earned.