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.

Eh... it's a fun conceit to think about, but, historically speaking, we already know how that battle turns out - extremely poorly for the ones using primitive fighting equipment, but not quite as poorly as the people with the technology anticipated when they picked the fight in the first place. We have a couple centuries worth of European history against various indigenous groups to back that up.

One interesting recent development in human history that might correlate with a story like this is how, once the bigger/badder/better urge is maxed out, the race suddenly focuses on intent and finesse. For example, the US could carpet-bomb Afghanistan with nuclear weapons if it was so inclined, but it chooses not to. So, instead, the US military is focused more on doing the most amount of damage in a very precisely targeted location under very precisely controlled conditions without doing any damage to US military forces or surrounding areas - hence the recent embrace of drones, laser-guided weapons, smart bombs, stealth, and so on. The result is a level of precision that was unthinkable by Soviet forces in the late '70s, to say nothing of the brute force methods of both world wars. Following this train of thought, it'd be possible that highly advanced space aliens might want to attack us to secure a particular resource but find our near-suicidal willingness to inflict as much harm to ourselves as our enemies morally, tactically, and politically untenable. Put another way, would you feel the same way about harvesting honey if it turned out that bees were intelligent, even though you know that bees routinely sacrifice themselves when they attack the beekeeper?

Oh, it's much worse than you think. Much worse.

If the companies you're thinking of actually acted as a self-appointed world government, we wouldn't be in the mess we're in - they'd at least try to make sure their own backs were scratched, if nothing else. The trouble is, nothing any of those banks own is actually worth anything. To use a programming analogy, our entire financial sector is abstracted into oblivion. Every single "asset" on the books is tied to some value extracted from another "asset", which in turn is tied to some value extracted from yet another "asset", that, 15-20 links later, eventually leads to actual collateral. This is due to our banking sector deciding at some point that it could get better returns reselling every scrap of paper they bought among themselves to each other than they could by investing their money into capital creation.

To better explain this, pretend you're on an island with two other people. One of you is good at hunting pigs. Another one is good at harvesting coconuts. A third is good at fishing. Between the three of you, you all make enough food to feed everyone, frequently with a bit left over. However, each of you gets bored with what you get, so everyone decides to trade with one another. Trouble is, nobody can decide, say, how many pounds of pig a coconut is worth. So, the three of you decide to use a small shell on the island as money. It's colorful and thus easy to identify, it's rare, and it's portable. Perfect!

One day, you decide you want a week off from your pig hunting duties. So, you start hoarding shells to save up for your week-long vacation. You charge a bit more for your pig than usual, you buy a little less fish and coconut than usual, and you spend more time between pig hunts looking for shells. Finally, you decide you have enough saved up where you can take the week off, so you do so. You stop hunting pigs and immediately start using your hoarded shells to buy coconuts and fish.

Sounds good so far, right? Well, here's the thing - since you're taking the week off, food production just went down 33%. On top of that, the number of shells being exchanged between the three of you is the same as it was before you took your week off, only there's much less to buy. In short, everyone on the island - yourself included - is screwed.

So, what does any of this have to do with the banking sector? Well, instead of investing in, say, fish preservation techniques, salted pork, better fish hooks, or a longer stick to whack the trees bearing coconuts with (i.e. capital improvements that benefit everyone), they've been investing in shells for the past generation or so and now we're all paying for it. Fun times, eh? But don't worry - maybe if we replace the shells with "sound money", maybe some shiny rocks, this sort of thing won't happen again. We promise.

I live in Reno and I'm paying $850/month for a two bedroom apartment, which is about middling for this market. Plus, I don't have a state income tax to contend with.

On the other hand, our unemployment rate in Nevada is the worst in the nation (13%+ in Reno, more than that in Las Vegas), starting IT salaries out here are at $25k/year with most people peaking out somewhere in the $50k range after a few years, there are never more than 30 job listings on Dice.com, and the vast, vast, vast majority of IT jobs here are roughly help desk level. So, it kind of balances out.

The mountains are nice to look at, I guess.

In a larger company, your advice probably makes some sense. Most smaller companies, though, can't really afford "bulletproof" utility-grade IT, which is where most of those policies come from. This alone will cause most small- to medium-sized business IT people to pause. For example, if you don't put some sensible Internet policies in place, you'll quickly find yourself spending all your time cleaning viruses off machines, and that's with gateway virus protection, mail scanning at the SMTP gateway, anti-spam technology, and local installs of some antivirus product. Once you start going down that road, you're trying to decide if you should restrict Internet access to a business-case justified whitelist (BOFH move, but it works), try to maintain blacklists of various "trouble sites" (nfl.com, Facebook, ad networks - but wait, marketing needs access to Facebook and Twitter, and why is Bloomberg not loading up correctly for the CEO with the ads off, and...), put together a PXE boot image for the network with automatic wipes of local machines (Wait, where did that document I was working on all day yesterday go?!), or just grind your teeth, order some spare PCs, and resign yourself to spending half of your IT department's labor on PC rotation/office virus removal. And yes, that's with Microsoft embracing user-level permissions; for most users, the distinction between "my computer has a virus" and "my user profile has a virus" is strictly academic.

And that's just viruses. Once you start talking about departmental applications, integrating devices you brought from home, and dealing with the fact that the C-level crew really don't want to replace several thousands of dollars worth of servers and software every 3-5 years unless something breaks, it starts to make sense why the "simple, easy solution" is neither simple nor easy.

I get the spirit you're communicating from. I even agree with it to a certain point. Unfortunately, life is full of trade-offs, and one trade-off most companies make is getting an IT infrastructure in place that "juuuust works" instead of one that works well enough to call itself a utility.

At one point, the company I worked for had to blackhole nfl.com and associated fantasy-football stuff because fantasy-football was eating up productivity when people should have been working.

This actually raises an interesting point - in most companies, IT is sort of "in between" layers of the org chart, so it doesn't really fit in. IT is just as answerable to the managers as workers, but it has power over the workers ("No more nfl.com!"). So, consequently, workers don't like IT so much - they're the "no fun" crew that prevents them from playing Adult Swim flash games all day and updating their Facebook statuses. However, since IT (usually) doesn't have the power to hire, fire, provide raises, or otherwise do anything directly meaningful for the average worker, there's no need for the average worker to hide their disdain for this particular font of authority. On the other side of the fence, management doesn't view IT as "one of them" because IT isn't (usually) directly responsible for the daily business of the company. IT is viewed as an instrument of management, just like sales, customer service, or any of the other departments of the building, so why should IT be treated any differently from the girl doing data entry for minimum wage downstairs?

I imagine accounting and human resources have similar issues, come to think of it, though those departments usually have a less direct day-to-day impact on how everyone in the company works.

Steve Jobs does have a hand in making the company successful, but that's because his true strength is in sales. That man could sell people anything in the world. He could make dirt seem like a desirable commodity. The loss of a salesman of his caliber will hurt Apple, but it won't hurt the products one whit.

Spoken like a true engineer. Here's the thing - sales and engineering have salutary effects on one another. Without sales, engineering never finds out what the customer wants - it just puts together stuff that thinks is "cool" and wonders why nobody's latching on to it (GNOME 3 being a timely example at the moment, but there have been other examples). Plus, sales makes it possible for engineers to actually get paid. If product doesn't sell, engineers don't eat. Just ask everyone from Taligent about that one. Or Apple from the Gil Amelio years.

Steve Jobs is a flawed human being with a rather frightening outlook on the direction of tech. All of that is true. He's also the one that convinced the world that Apple could still "engineer" in the late '90s when all they had was a bunch of G3 motherboards, plastic cases, and a shortage of floppy drives. He sold the world that Apple was a design company worth investing in at a time when Apple had long since run out of money for product development. He then used his success at that to build Apple into a company that actually does design things - good things that people want. Remember what smartphones were like before the iPhone? I do. I also remember when RIM's servers taking a dive was big news for the enterprise world. Know why their servers don't crash now? Because their traffic is declining, and good riddance. I also remember what it was like trying to browse the web on a Windows Mobile 6.1 phone. I remember trying Firefly and various other browsers on the 32 MB memory of that poor, underpowered phone, and marveling at how similar it was to browsing the web in Windows 95, with various "out of memory" messages and the like. The iPhone, for all its faults, actually brought mobile computing into our hands, instead of throwbacks to the mid-'90s that we told ourselves were "smart" so we could sleep at night.

Steve Jobs had his faults, but you have to admit - he was a hell of a businessman, and his vision will be reflected in everything we do on our computers for years to come. Sure, he didn't invent any good ideas. GUIs came out with Xerox PARC. MP3 players had been around for years. Smartphones had been around for ages. Even the App Store can be traced back to Linux package management systems. Thing is, he was the one who saw those ideas and actually made them cool and intuitive for everyone. That's a skill, and one we should all strive for once in a while.

That's because Samba went GPL3, so Apple is having to roll their own CIFS implementation. I imagine it'll take a version or two before Apple gets within sniffing distance of feature parity.

Well, only in a base-26 alphabet. If we expand our horizons to include non-European alphabets, we'll be fine for a while yet.

I think they ditched the "license per IP address" model two or three years ago. I do agree that, until that happened, it was a royal pain once you hit that limit, though.

For smaller networks, I like Fortigates, though they can be a little... finicky to configure. Unlike the "overgrown Linksys" nature of the Sonicwall, you have to really pay attention when configuring Fortigates to do much of anything useful (do I need an "IP Address" or a "Virtual IP" to get this port forward going?). I've also been less than thrilled with their IPS products. For just basic firewall/routers, though, they get the job done.