The US has defaulted on sovereign debt a number of times in the past. However, it's not likely that the government would do something default-like regarding the "trust fund" bonds. Among other not-default mechanisms, the government could cut or even eliminate benefits in those programs so that SSA and CMS never need to redeem them; that was the point of Flemming v. Nestor.

As a side note, you could eliminate all US military spending from the budget and still leave a sizable deficit. Social Security is getting close to the size of the military budget, as is Medicare. Those slices of the budget are growing rapidly -- and with no real end in sight, which is why entitlement reform is critical to controlling the deficit.

Your -UK suffix is showing. In the US, Social Security is collected by the federal (central) government. That government writes contracts for approximately none of the "basic infrastructure" you describe. Yes, it subsidizes road construction by the states, but things like power generation and delivery are mostly performed by private companies with oversight by state regulators; private rail freight companies subsidize the national passenger rail company; and so forth. States (and localities such as counties, towns and cities) collect taxes independently of the federal government, and the federal government has no real ability to collect money directly from state or local governments.

"Hollywood accounting methods"? Are you talking about the Social Security and Medicare "trust fund" gimmick? If so, that supports Solandri's point: Because people were willing to pretend that FICA are not ordinary taxes, and that payroll taxes went into some special pool of money, it was easier to use FICA surpluses to subsidize deficits in the rest of the budget. If you're talking about something else, perhaps you should be more specific.

If you think that Social Security or Medicare are "earned benefits", that boat sailed 50 years ago; the Supreme Court disagreed with you in 1960 (Flemming v. Nestor). Recently, President (George W.) Bush wanted to give each worker a real retirement account where the worker would have ownership, but your side threw an epic fit over the proposal (for transparently bad reasons).

If you think 1950's-style tax rates would be an effective solution, you've been reading too much Paul Krugman without engaging your brain. If you think bringing one or two hundred thousand deployed servicemen and servicewomen back home -- given the general economic climate, with the likely effect of dumping either them or others into unemployment -- would solve the budget deficit, you again haven't given the matter enough thought.

Usually a meeting of the minds is indicated by explicit compromises -- or at least negotiation. Ambiguity in contracts of adherence (also called standard form contracts or boilerplate contracts), where one party has no realistic option to negotiate terms, is supposed to be construed against the interests of the party who offered the contract.

AT&T most certainly care about the structure of the data on their network. They designed the thing -- including deciding what encapsulation to use inside their network. The user has neither insight into nor control over what is going on, so AT&T should have to describe their metering methodology, make it roughly consistent with what an end user can measure, or both. Anything else is tantamount to AT&T saying "trust us -- we have a track record of screwing up customer bills, but yours are juuuust fine".

If AT&T were honest about bandwidth costs, potential customers would at least be able to compare competing services. Customers can't do that if AT&T comes along and secretly gooses the bandwidth consumption in order to inflate the bill.

Including ATM overhead, and probably even just the AAL5 overhead, would probably be grounds for a lawsuit because that overhead is an artifact of AT&T's network design that is invisible to the user and out of the user's control. What would you do if a shipper charged you by the pound to ship a box and then also billed you for the weight of a hand truck that they decided to send along for their own convenience in handling your package?

Unless someone is sending an awful lot of really small packets, the 40+ bytes of TCP/IP headers per packet are not going to add 20-30% to the data that is being sent. For example, the "Simple IMIX" as defined on WIkipedia has 58% of packets being 40 bytes long (they are common because they represent data acknowledgments with no data going in the other direction), probably significantly underweights the number of 1500-byte MTUs, and still only has ~12% TCP/IP overhead. It would be grossly inappropriate for AT&T to include any packet overhead beyond TCP/IP because any lower level overhead is an artifact of AT&T's network design that is outside the control of, and opaque to, the end user.

Don't forget to include the almost equally textbook identity theft claims when filing the defamation action...

In this case, MAC = Mandatory Access Control, and the GP was right.

One part of engineering is applying science. Much more of engineering is predicting problems and designing ways to avoid or mitigate them. Very often, these problems are outside the scope of the field's science.

For example, one hard part of software engineering is writing good requirements. The customer (or end user, or whoever is generating the requirements) seldom has a very good idea about what they need until they have something in hand that mostly works, and it's even rarer for them to have a good understanding of what is practical. What is practical boils often down to in-house expertise, reusable work products and development budgets rather than what the science allows. Once you know how what is needed and practical, the next challenge is to write a requirement that captures that while also being verifiable. Most systems that people care about cannot (practically) be formally proven -- they are too complicated to be affordable, techniques for doing so are unknown, and so forth; instead, the project's engineers need to have good judgment about what kind of design verification are appropriate and how much is needed on which components in order to meet the project's goals.

Congratulations on your 20-line programs written in languages that hardly anyone cares about.

(I kid a little: People have developed formal proofs of separation kernels that are hundreds of lines long -- and published because doing so requires fairly novel techniques. And people sometimes do formal proofs of Java source code, which some people care about. But most programs that get formal proofs are tiny -- or tiny parts of larger, more complicated systems -- and an awful lot of formal provers only work on niche languages.)

Your opinion is idiotic and wrong; the title "software engineer" omits the key qualifiers "consulting", "professional" and "-in-training" (or abbreviations thereof). The law is refers to abbreviations such as "P.E." for professional engineer. Someone calling himself a "software consulting engineer" would probably run afoul of the law, and someone using the title "consulting software engineer" would be on very questionable ground, but the title "software engineer" is not covered by the law.

Legal restrictions on "Engineer" as a job title are in some ways like laws requiring interior designers or casket salesmen to be accredited by industry groups -- motivated by a desire to squelch competition. On the other hand, most engineering accreditation groups also put a strong emphasis on ethics: For example, someone who is a member of one of those groups has an obligation to keep the public interest in mind as they design objects or processes, and to push back (or report to the authorities) efforts to cut corners in ways that harm safety. There is also usually an effort to provide workplace mentoring so that new graduates are paired with someone who has more experience with the more practical (and less schoolbook-related) challenges of the work.

As a software developer (and sometimes engineer) who has worked on systems that involve mechanical, electrical, software and systems engineering, I try to restrict "software engineering" to projects that involve careful and informed analysis of trade-offs to meet specified goals, planning and managing the development cycle (from requirements analysis and derivation through programming, integration, testing against the requirements and testing against the user's need, and delivery), and then carrying through with something that more or less resembles the plan. If a project is less rigorous, I prefer to call it just software development.

In my experience, the usual areas where a project fails to qualify as "software engineering" are the analysis (most common), testing (sadly common) and requirements (less common). That isn't necessarily a bad thing -- for example, time to market or budget might be more important than delivering a well-understood product with known high quality. On the other hand, a project with a foreseeable impact on people's health or safety is a project that needs analysis, planning and testing that are proportionate to the risks. Because they do not directly help build a deliverable product, analysis, requirements and testing seldom get the attention or credit they deserve.

There are a number of good reasons to believe that email voting is less secure than snail mail. Among them: it is easier to change, forge or destroy electronic records than physical ones; there fewer legal protections for email than postal mail; and there is much less experience with email voting, so mistakes are easier to make and fraud is easier to commit.

When I see a 2.6 MB kernel module (for fglrx; I recall Nvidia's being closer to 9 MB), my assumption is that it is mostly code that executes on the host. Code or data that gets loaded onto the peripheral can easily live in a file, or in a executable section that gets discarded after use. Given how specialized the devices are, how much translation and optimization is needed to convert application-level APIs to hardware operations, and the fact that the vendors have begged off on providing host-side source code because of NDAs with third parties, it will take a lot of evidence to convince me that the size of the binary blobs is due to peripheral code rather than (intentionally proprietary) host code.