Contrary to popular myth, precious metals are not a guarantee of sound money. For starters, governments could - and did - routinely change the peg rate, which precious metals would back the currency, and plenty more. Also, even with a nominally precious metal-based currency, it was quite easy for governments to debase the currency, either by changing the alloy mix (when coinage was in use) or just by overprinting gold certificates (France did this just before the first Revolution; Germany tried this during World War 1). This doesn't even throw capital controls into the mix, or even local inflation, like what happened in California during the '49 Gold Rush.

Pretty much this. There are three ways to handle disagreements:

1. Engage in a respectful, carefully thought out conversation weighing the pros and cons of each position, then achieving some sort of consensus.
2. "Agree to disagree", then passive-aggressively do your own thing or otherwise lobby with others to follow your path over the other person's path.
3. "Be a dick", call the person out, and make it clear that, since you're the one making the decisions, you are the one making that decision, not them.

Option 1 is great when you have nothing but time on your hands and/or when you're dealing with someone whose opinion you trust. It's also only useful when there's a clear definition of "right" and "wrong" regarding the topic at hand - more often than not, choices in life and engineering pretty much boil down to "which trade-offs suck less for the domain we're working in", which are more subjective than not in most cases. Option 2 is the default position drilled into our heads during school, which is a useful default when you're dealing with equals or people who you have no authority over - I mean, sure, you can yell and scream at them, but it's not like they're required to listen. The catch with option 2, though, is that, though it leads to less hurt feelings in the short run, you're as liable to have different factions competing against each other to prove who's "right", which can lead to some major issues down the road.

Option 3, meanwhile, is useful when you're in a hurry, a decision needs to be made now, and it needs to be made decisively. The goal here is to nip a problem in the bud before it metastasizes into something serious and political. In this case, Linus wants to enforce some discipline on the code review process because his time is finite and the deadline is near for 3.10 to get out the door, and "receive lots of crap code and reject it" doesn't solve that problem. He needs to not receive non-essential code in the first place. The only way to do that is by convincing those committing code to make only meaningful commits, either through well-defined requirements (tried; apparently that's failing), polite warnings (what Slashdot picked up here tonight), or "being a dick" (Linus will continue the beatings until morale improves if his warning isn't heeded).

Personally, I've found that the sort of people that claim "being a dick" is the sole refuge of people that enjoy being dicks are the sort of people that have a reflexive inability to defend their opinions under any sort of sustained criticism and just assume that, if their "brilliance" needs to be defended, it's because it's being witnessed by simpletons that just "don't get it". From where I'm sitting, that's a pretty dickish and passive-aggressive position to adopt and I... well, come to think of it, I actually do enjoy being a dick to people that think like that. Seriously, screw them.

Huh. Guess I pretty much proved the grandparent's point right there, didn't I?

Sure you can. Heck, if you have the right version of Windows, you can even eschew the GUI entirely and go straight to the command line. Or, if you're looking for a lightweight DE, you could opt for the Minimal Server Interface.

Granted, it's not quite fvwm, and it's certainly not available on consumer-grade Windows, but it's out there if you really want it and are willing to fork out the money for it.

The SMB space is where cloud adoption is going to spike. Truth is, a lot of smaller shops really have no business hosting their own email, much less some of the other stuff out there (document management servers, etc.). Sure, the "cloud" isn't going to be for everyone - dentists and doctors want their x-rays to show up on their screens now, not when it's done uploading to their EMR and downloaded back to their terminal; forget "data security", THAT'S the big holdup there. But, for smaller construction shops, legal, insurance, and the like? You mean to tell me that they can't convince an auditor (if they ever see one) that their cloud setup is more secure than a server sitting under someone's desk or in an unlocked closet somewhere? Truth is, most of the changes coming to IT from the "cloud" will have little bearing on larger corporations; they're big enough to hire enough IT people to get the job done right internally, and they have been forever. Where the big change is coming is for your SMB IT consultants and lone wolf "IT Directors" who will suddenly find themselves spending much less time idling in front of Event Viewer and swapping backups, and more time implementing SharePoint portals or looking for career changes. Bear in mind that Microsoft has already told the SMB space to stop self-hosting their own email; Windows SBS (with Exchange) is now officially a thing of the past.

Pretty much this. I'm dual-booting Ubuntu 12.04 and Windows 7 on my cheap Acer (AMD CPU + Radeon Mobile) and the difference in performance is galling. Framerates and CPU loads on Windows 7, at least once I get past boot and the usual start-up virus check, are consistently lower in Windows 7 than Ubuntu for comparable programs. This even holds true for basic software like Firefox and Chrome(-ium, on the Ubuntu side). Much of this, I suspect, has to do with Radeon Mobile's use of "HyperMemory", which Windows seems to actually call from and pull from system RAM, while Linux just keeps the BIOS fixed at 256MB of "VRAM" and puts everything else in CPU-addressable RAM instead.

Granted, Ubuntu has Unity, which is an absolute hog, so that might not be an apples-to-apples comparison; then again it's not like Aero is "low impact". It also doesn't help that a lot of internet-facing applications (Flash, most browsers) are either giving up on Linux entirely (Flash) or are primarily optimized against Windows graphics calls since Linux browser programmers aren't sure whether OpenGL will really be there for them or not, and in what capacity.

Those who are throwing out the "tool for the job" line I think have it about right - Linux was always optimized for server workloads first and everything else second. It makes an excellent server in most circumstances and a poor desktop, almost like a backwards Mac OS X. There's nothing wrong with that - we need good server operating systems. However, there's no shame in admitting that a favored tool isn't the best tool in all circumstances.

To be fair to kids, assembly really isn't the "basics" for their computing world anymore. I guarantee you kids interested in computers these days know more about markup and scripting languages than most greybeards knew about them back in the early '80s, which is as it should be - the only thing most kids in the '80s knew about punch cards, if they knew anything about them, was that they made excellent bookmarks. You also didn't see a lot of kids picking up COBOL, either.

Let's go through the list...

Housing construction: In Europe, current population is either stagnant or shrinking in most countries and the population generally doesn't move around much - it's not entirely uncommon for a family to still be living in the same house their great-great-grandparents moved into during the start of the Industrial Revolution. In America, it's a different story - our population is steadily increasing through a combination of natural birth rates and mild immigration, and our population is arguably one of the most mobile on Earth. Consequently, American housing reflects American needs - it doesn't need to hold up multi-generationally because it won't be in use multi-generationally. It just needs to hold itself together long enough to get the kids into college so the parents can retire into a different, smaller house, preferably one in a warmer climate.

Household appliances: Eh? All the appliances in my apartment are at least a good 15-20 years old and they're holding up okay. Bear in mind here that, if we're going to get serious about energy efficiency, we probably shouldn't be encouraging people to use 50 year old appliances that work "just as well as when they were new".

Cars: You're kidding, right? I've seen European cars. I've owned European cars. There's a reason they're a niche commodity in America - they're expensive and don't hold up nearly as well under American driving conditions as Japanese and (some) American models. Plus, due to the higher concentration of population in Europe, mass transit is used more widely and the road system isn't generally as accommodating as America's - this means that there are a lot of poorer Americans buying cars here that would normally just take a bus or a train in Europe, which means there's a large, paying market of people here that can't afford a C-Class. I'll note that there are several European brands that tried to set up shop here and failed miserably, all with horrific reputations for reliability by the time they were done (anything British, French, and Italian comes to mind, with FIAT doing its best to prove it's learned a thing or two since the last time they were here). Even Volkswagen has a well-deserved reputation for shaky reliability and build quality out here, though I've heard that has as much to do with the price point VW's trying to meet in the US as it does anything else.

Put another way, Americans look at TCO just fine - we're just operating under an entirely different set of parameters than Europeans. Well-built 100-year-old houses are still 100-year-old houses with 100-year-old wiring, 100-year-old plumbing, and 100-year-old room sizes - in our case, we have enough open room and enough money to replace those with newer, better designed houses, and since we know we're just going to replace them again in 25-50 years, we're not going to overbuild them. Similarly, the American definition of a "well built" car is wildly divergent from a European definition - since we practically live in our cars here, we want something that will last 250,000-300,000 miles and/or 10-15 years of constant day-to-day driving first (that's 400,000-500,000 km), we want it to be comfortable to sit in for long periods, and if it can also go around a corner without swaying to-and-fro, so much the better; this, I'll note, is the opposite order of the European definition, which better reflects European needs and conditions. And so on.

Tell that to lawyers that need it to access PACER or their local court filing repository. Or tell that to various medical professionals that have line-of-business apps written in Java (recently stumbled across an pano controller package written entirely in Java - that was cute). Or tell that to certain financial industries that use Java to submit various bits of paperwork (if you're a merchant filing for credit card processing, there's a decent chance your application was scanned and uploaded using a Java app called "AMA", depending on which platform your processor is underwriting with). Or tell that to businesses that electronically deposit checks - quite a few banks out there use scanners with Java software to get the checks from the business' PC into the banking system.

Java's actually fairly commonly used for line-of-business applications because it's fairly easy to find Java developers ("easy" being synonymous with "cheap"), the tools start at "free", it's sort of platform neutral, and it's been around for a while. Plus, a lot of those Java line-of-business apps were first written 5-10 years ago and, well, they still basically work - given a choice between paying for a total re-implementation of some tool that works "reliably", doing the necessary field testing to prove it's at least as secure, functional, and stable as the current implementation, or just periodically testing it against the latest version of Java, guess what most businesses do?

Now you know why Java exploits are a big deal.

Yes, but they had abortions in the 19th century, too.

In my experience (and I do do development in environments where this comes up frequently), it is not at all unusual for applications to either rely on buggy behavior of another piece of code, or to make unwarranted assumptions about how another piece of code works, that happens to be valid under some circumstances but not others.

Which is why Linus' policy is that, when the choice is between userland compatibility and better adherence to theoretical documentation of the kernel interface, tie goes to userland compatibility. This is smart - Linux already has enough issues with userland apps breaking backwards compatibility to scratch itches that nobody really has (see GNOME 3, the entire audio stack, etc.); if the kernel is disciplined, at least, it keeps the whole environment from turning into a bug-ridden tar pit.

As for Linus' attitude, well, I have to agree with Linus on this one. Fix the mistake first, either by removing the patch that broke everything or quickly implementing a fix, then ask questions. The first rule of kernel development should always be "Do No Harm". If you're in charge of some part of kernel development and you find yourself breaking that rule, you need to un-break it ASAP, then assess how you found yourself breaking it in the first place. Unfortunately, Mauro wasn't grasping that - he was too busy asking "reasonable questions" to undo the damage that his commit did when his first priority should have been to stabilize the kernel. Don't get me wrong, Mauro's questions are important and they do need to be answered, but only after userland is back to the condition he found it before the commit. And not until then. And *certainly* not with the mainline kernel.

I never did understand the point of permanent storage of nuclear waste in a centralized location. You're telling me that, over 10,000 years, nothing is going to change in terms of reprocessing tech? Heck, we recycle household waste now that nobody knew how to *create* 100 years ago, much less reuse.

Then there's the issue of actually designing something to last for thousands of years. That sounds like an old-school "Popular Science" cover article than something anybody should take seriously enough to spend billions on. There are just too many unknown unknowns - geological or human-caused.

It's not terribly difficult from a technical perspective, but there are a few caveats to keep in mind:
- Everybody and their mother (at least in accounting-related clerical work) knows Quickbooks. Whatever you come up with would have to be similar enough to justify the training expense.
- Intuit really does spend a lot of effort keeping track of various local, state, and federal regulations, at least in the US, and applying them to their software. That's not cheap or easy.
- Since Quickbooks is something of an "industry standard", it's possible to share Quickbooks files among necessary individuals (outsourced accountants and the like) and know that the books are getting from point A to point B. Not everyone has a copy of, say, Peachtree lying around, to say nothing about GnuCash or anything else.
- Accounting is generally not something that businesses start "experimenting" with. Predictable and supported are what they're looking for. Given a choice between a technically superior product from a company that just received angel capital last week and a predictably wrong product supported by a company that's been selling and supporting accounting software for 30 years, most businesses will go the safe route and buy the technically weaker package. It's actually pretty rational if you think about it; switching accounting packages is not trivial by any stretch of the imagination, so picking the product from the company with proven staying power makes a lot of sense.

Personally, I think Quickbooks is kind of the Microsoft Access of the accounting world - oh yes, there are better, far more stable tools out there, but too many people know Access and its quirks for all but one or two of them to catch on in any meaningful sense. That's inertia for you.

I agree with the deadwood issue, but there are also some dynamics that favor having work done by government. The big one is that there's essentially no profit motive. In a well-functioning federal agency, all of the staff are encouraged to "do the right thing" for the people they serve, rather than maximize profit.

The real problem with the lack of profit motive isn't feather-bedding or anything crazy like that, though a fair amount of that goes on. It happens in the private sector, too. The real issue is that management is kept accountable by profitability - if they get penny-wise and pound foolish, the market will (eventually) punish them for their shortsightedness (yes, yes, after Wall Street's computers spike share prices for a month so investment bankers can extract every ounce of value out of the company first). In government, however, the only thing keeping anyone accountable is popular opinion. If the people think you're saving money, even if it's by throwing together 23 different layers of "accountability" between a funding request and the request being fulfilled, they'll reward you. If the people think you're spending too much, regardless of value you're returning to the community, your funding will be cut. The result is that pay and funding are directly tied to appearance of performance (plus bits and pieces of patronage, where available), not to actual performance or value.

The worst part is when the same people running government institutions decide to treat their systems as "best practices" and insist on forcing private companies to adhere to them, too. Then you end up with well-meaning but ill conceived bits of legislation like Sarbannes-Oxley.

Short answer: Supervisors, which, contrary to popular belief, is not management.

Long answer: If you're operating within the same time span as your employees, meaning your deadlines are their deadlines and vice-versa, you're not management or, worse yet, you're not managing.

A supervisor has the job you're describing. They usually are a former veteran in the field, someone with sufficient domain knowledge in the industry to know when an employee is doing their job, when an employee that's capable of doing the job is sluffing off, or when an employee is simply incapable of doing the job regardless of how much you incentivize them. A supervisor isn't formally trained on how to supervise - chances are, they've been supervised long enough where they've seen what works from their predecessors, what doesn't, and guide their approach accordingly. In military terms, they'd be an NCO (Corporal, Sergeant, etc.). How much latitude they have, and how they motivate or monitor the employees, is defined by management, depending on business needs and corporate culture.

Management, meanwhile, is a formally defined skill with lots and lots of science behind it. Management's job is to provide differing levels of strategic direction for the company, depending on time span and objectives. The purpose of management is to make sure that each assignment provided to staff is part of a larger goal dictated by business needs and that each assignment is broken down and compartmentalized into appropriate-sized units, as dictated by the capabilities of each staff member or group. So, for example, a software architect might be assigned a multi-year software design project, while a starting coder would receive something fairly simple, like "Implement function X within the parameters Y specified here," with a deadline (implicit or explicit) of at most a week. To accomplish this, systems must be created, maintained, and monitored to ensure that there is consistent, positive output from the start of a project (or set of projects) to the end of one. When management does its job well, predictable, sensible output is the result (see recent iterations of Ubuntu and Windows, at least post-Vista). When management does its job poorly, the systems break down (see Longhorn, Apple in the '90s before Jobs reclaimed the throne, pretty much anything GM has done in the past 40 years). In military terms, management would be your officers (Lieutenants to Generals, depending on branch, of course).

Now, getting to what you were discussing, yes, it's true that Slashdot has more than its fair share of self-entitled 2%ers (or people that wish they were 2%ers and want to be treated accordingly) that think they should be given a six-figure paycheck, a well stocked lab, and a fridge full of caffeine so they can change the world, and view any failure to accommodate that vision as "poor management". In reality, that might be the start of an effective system of production, or it might not - depends on who's working for you and what you're doing. However, as GM learned the hard way in the '60s and '70s (and Toyota learned by studying Deming, who knew better as far back as the '30s), even "unskilled" labor benefits from frequent job reassignments, variety in work, and occasional moments to stop and think about the bigger picture. This doesn't mean letting the employees turn the company into a re-enactment of the "Lord of the Flies" (or whatever you want to call the excesses of the now-legendary Dot Com bubble 'companies'), but it does mean treating them as stakeholders that should be interested in the success of the company and whose opinions should be respected and rewarded when they lead to improvement and growth.

From a management (or even supervisory) standpoint, this means that, if your system calls on lots of yelling, screaming, and berating to get employees to do something they don't want to do, your system is going to only return just enough to avoid further yelling, screaming, and berating... usually. Maybe you're in a market where the resulting mediocrity is all you need to keep money in the bank - if so, good for you! If you're not (and, chances are, you're not), though, treating your employees at least halfway decently will not only help the good ones stick around, it might cause the mediocre employees to strive for a bit of greatness and outperform their natural inclinations from time to time.

Don't believe me? Ask the experts. This is all old, old hat.

The issue with "free" infrastructure isn't moral hazard. It's expertise and cost. If nobody around knows how to maintain a road, it won't be maintained, regardless of short-term economic benefit. Similarly, if the road or bridge doesn't bring enough benefit to the local economy to pay for maintenance, it won't happen.

This is the real problem with dumping and helicopter development (i.e. flying foreign engineers and crews in to build something, then going home) - the economic incentives from this behavior perversely guarantee that locals will never pick up the experience and expertise required to maintain their economies. That's great if you're a multinational resource extraction company looking for cheap, desperate labor willing to work in mideaval conditions. It's less great if you're a local trying to build a better life for yourself or your family.