I have yet to hear a serious argument for why the world will be injured by behaving as if there is an ozone or climate problem (if there is not), and so I just don't understand why anyone ever makes this argument.
Well, that one's easy. If there is no real problem, but we still restrict doing things that we think are causing that non-existent problem, then we reduce quality of life. We choose modes of transport for people and goods that take longer or cost more to run, or avoid the journeys altogether. We rely on less efficient means of generating power. We restrict the use of otherwise beneficial devices that emit certain chemicals.
This isn't to say that I disagree with your basic point. It's simply that there is a significant downside to going all eco-friendly in terms of quality of life, at least in the short term until our economic model and technological progress can compensate.
(As it happens, I am somewhat sceptical about claims that the world is suddenly going to end because of global warming. Lots of people are suddenly very sure about this, because all these eminent scientists suddenly agree it's true. And yet, most of them didn't for decades beforehand, and no particular new evidence has been found. The current political climate is more about politics than climate. This is a different issue, though.)
You're right about the hardware support. I have been planning to move my home PC to dual boot with Linux since forever: I've been leaving separate hard disk partitions free for this purpose for years. But I never have actually installed Linux on my main home machine, because every time I come to look at it and do the research, I find showstopping issues with some piece of hardware or other.
I don't think that's the biggest obstacle to widespread Linux adoption, though. In fact, the real problem with Linux from the point of view of average home or office users has nothing to do with Linux itself. It is simply that, as TFA suggests, the applications just aren't there for serious users. To get people to shift away from the Windows platforms they're familiar with, Linux must offer better applications, yet there is not one "killer app" for Linux. Many of the best mass market OSS software is also available for Windows, particularly on the programming and server software front where Linux has traditionally been strong. For end users, there are commercial offerings on Windows as good or much better than almost anything on Linux.
The really silly thing is that a lot of this is actually caused by the community-driven OSS model that prevails in Linux world, which admits the kind of politics that would be squished by senior management in a traditional, commercial software development company. Your average end user doesn't care about GPL2 vs. GPL3. He doesn't need OpenOffice to try and be an MS Office clone, because he's got MS Office. He doesn't care about your open standard calendar support in your mail software, he just wants to connect to his corporate Exchange server. He doesn't care that Firefox is just following W3C recommendations in how it renders the page, when the page looks wrong in Firefox but right in IE.
This isn't to say that none of these things matters. To you and me and those who would like to see a better world, the technical details and open standards are important, and for some of us, perhaps the free software philosophy is too. But the bottom line is that the end user doesn't care. He just wants a system that can help him to do his work, relax at home, or whatever. As long as Linux doesn't have the same level of key application support that Windows has, and some "killer app" alternatives that are substantially better than what is available on Windows, it will never be the "year of Linux on the desktop" no matter how good the operating system itself may become, how easy it is to install, how pretty the widgets are in the GUI, or how many geeks object to the de facto standards and vendor lock-in that prevail in the Windows world.
It's a solved problem if you're a smart programmer sitting down to write a program. It isn't a solved problem if you need a simple rich client and somehow want to get out of doing it yourself:-)
Fair point. I'm definitely talking about the programming models and design techniques here, not the specific implementations, which I agree are sometimes amazingly poor for such a big, fast-evolving industry. For what it's worth, I think this applies to programming language design generally, not just in the particular area of concurrency.
That's what I normally do when I need multithreading for throughput; I write a nice high-level API that just happens to map perfectly to my needs, and I implement it using locks, mutexes, and conditions. It works, but it feels a bit like writing my own linked list implementation.
Yeah, I know what you mean. Whenever I start out on some new logging or unit testing code, I get that sinking "reinventing the wheel" feeling, too.
But then objectivity kicks in. This is not the same as rewriting a linked list. We have programming techniques that let us express our wish to reuse generic linked list code with a single line of new code. Linked lists are neat, self-contained entities, readily generalised, and easily understood in isolation. The kinds of frameworks we're talking about here, for things like multithreading, logging and testing, aren't there yet: they still spread through your new code, taking up residence like a well-worn sofa, and just about as hard to adapt or remove if you later decide you want to do things in a slightly different way.
When we have developed tools to abstract this complexity away, so that using these aspects of the code is really just a one-liner as well, then I will agree with you about having a collection of useful "off the shelf" libraries. But until the effort to use the library is substantially less than the effort to just build the necessary functionality in using the basic APIs, and the power of the libraries is substantially higher than what you get with those raw APIs, I don't think we'll reach the point where bringing in a multithreading framework is a no-brainer the way that reusing a linked list is today. I look forward to the day when that happens, because it will make life easier for many programmers, but from what I've seen, the kinds of libraries we're talking about aren't quite there yet.
This is the basis of the disagreement. My desktop has plenty of power, but too often I see apps balk or become unresponsive because of poor handling of concurrency. Even popular, high-profile apps with lots of resources behind them occasionally suffer, and less-used apps can be quite horrible about chronically locking up for a few seconds as you go about your work.
Sure, but that has been the case for years. The delay isn't because of multiple cores or processors, it's because of kindergarten design mistakes in a certain kind of architecture, and it's been a solved problem for a long time.
What the serious people are talking about is taking advantage of multicore/multiprocessor hardware by parallelising time-consuming algorithms that have typically been specified in terms of a single thread until this point. This is where the hard problems are, and where the big gains are to be made.
I don't think those building blocks are what people are calling a framework in this case; they mean something higher-level and more concrete that has design implications for the rest of the system, rather than being moldable into any design. That's why there are so many of them. Consider the multiplicity of logging frameworks for C++, despite them all being made out of file handles and objects.
Sure. But again, that's looking at the easy part of the problem. Once you've worked out the general architecture you want to use, just adopt whatever APIs you need to support it. If you've made the right decisions up to that point, the specific choice of library doesn't much matter.
From what I've seen so far, a lot of these libraries are much like logging or unit testing frameworks: sure, you can use one, but it's almost as much effort as just incorporating the equivalent functionality in your design from scratch. I suspect you have to reach a substantially higher level of abstraction, perhaps serious message passing frameworks or transactional memory, to get much advantage over using pretty raw concurrency and synchronisation APIs with a simple wrapper layer.
Actually, according to copyright law in most places and glossing over the use of "stealing" for "copyright infringement", yes, making those mix tapes was technically illegal. This is one reason I believe places like Europe need something closer to US-style fair use exemptions for copyright, instead of the watered-down, half-hearted framework allowed under the EUCD.
If you read between the lines of the Gowers report in the UK, for example, it sounds a lot like his team concluded that this was justified, but felt that they could only explicitly advocate changes that weren't contrary to the overarching EU framework. Thus they proposed an exemption for format shifting (which, incidentally, the big record labels already publicly said they'd turn a blind eye to in the UK — how does that fit with the Sony lawyer's statement here?). However, they did not go as far as proposing what I would like to see: a more general private use exemption, where essentially once you've got legitimate access to some content for yourself, any convenience copies for personal use are OK (format shifting, back-ups, mix tapes, etc.) but broadcast or distribution to others is still against the rules without a suitable additional licence. It seems to me that this is entirely consistent with the basic principle of copyright, and the only harm it does to content providers is to screw those who want people to pay for the same thing multiple times based on legal technicalities.
Several of my favourite quotations come from H. L. Mencken, who once observed that "The trouble with fighting for human freedom is that one spends most of one's time defending scoundrels. For it is against scoundrels that oppressive laws are first aimed, and oppression must be stopped at the beginning if it is to be stopped at all." The problem here, of course, is that even in these early stages, it's not just scoundrels who are being caught in the net.
Have you ever known anybody to say: "There are just too many girls to choose from, I guess I'll go hide in the basement."?
Have you never heard the expression "too much love will kill you"? Never been in (or seen) a situation where someone is torn between a relationship with one person and with another, when they genuinely care for both?
The results of such a dilemma are usually very unpleasant for the losing party, and all too often don't work out for the others either because there's that nagging doubt about whether the eventual choice was the right one. People can put off making that choice for a long time, just to avoid the sadness and doubts. And that's (usually) just with two alternatives.
Now, clearly a choice between programming libraries isn't going to have the same kind of emotional effect on a normal person. (I'd suggest that if it does for you, then you need to reevaluate your priorities in life!) But the basic situation is still the same: analysis paralysis, where you're so afraid of making the wrong choice that you don't commit to any approach at all.
I always find it amusing (in a sad kind of way) how people talk about Herb Sutter's "call to action" over this. It's not that I've got anything against Herb himself: he's a decent writer, an excellent speaker, and a guy who can use the word "expert" legitimately in areas like C++. But it's also not like he's the first guy to notice that modern desktop computer architectures have been heading for parallelisation rather than increased speed for several years now.
Despite being right in the thick of this culture shift myself — I'm sure I'm not the only one here who has been talking about this for a while, and is just seeing management catch up — I don't think this is going to be that big of a deal for most people. The harsh reality, for the buzzword-wielding consultants rubbing their hands with glee at a new programming approach they can hype up, is that most people just don't need all this.
Your average desktop PC is more than powerful enough for most things that most people do with it: Internet communications, writing documents, working with databases, shop floor software, and the like. As long as the operating system is reasonably smart about scheduling, the guys writing these common types of applications don't really have to know anything about multithreading, locking, message passing, and all that jazz. Similarly, your average mobile device has more than enough juice to dial another phone, write a quick e-mail, or capture a digital photo.
At the other end of the spectrum, serious servers (database, communications, whatever) have been dealing with parallel processing of many requests since forever. High-end systems doing serious maths (the guys modelling weather systems, say) have also been using massive parallelisation on their supercomputers for zillions of years now.
There is a gap between these different areas, which we might traditionally have called the "workstation" market: the guys doing moderate number crunching for CAD, scientific visualisation, simulations, and the like. Many modern games also fall into this classification. This market is ripe for a parallel processing revolution, because historically it hasn't followed this approach very much because the hardware wouldn't really take advantage of it, yet the extra power is genuinely useful. But I don't think this represents some huge proportion of the software development industry as a whole. The guys working in these areas tend to be pretty smart, and will no doubt adopt useful practices and conventions fairly quickly now that the hardware has reached the point that they are useful.
As to what those conventions are, I just don't buy the whole "choice overload" theory. There are relatively few basic models for parallel processing: for example, you can have no shared state and communicate only through message passing, or you can have shared state. In the latter case, you then have the question of how to make sure that the sharing is safe, which leads to lock-based or lock-free approaches. Funky toys like transactional memory run at a slightly higher level than this, but they are ultimately constructed from the same building blocks, and again there are only a small number of approaches at this level to consider.
I'm not familiar with all of those libraries mentioned in the story, but I'll bet that those three classifications (no shared state, shared state with explicit locking, shared state without explicit locks) probably cover the models used by most if not all of them. If you understand the trade-offs in those, you can produce a sensible design, and then the toolkit or framework you use to code it up is mostly just an implementation detail. Given that the trade-offs are pretty obvious and will often steer projects clearly in one direction, I don't think there's really that much to choose at all.
The problem is, laws like this aren't generally being used to abuse our population en masse (though of course they could be used to "justify" doing so in future). Right now, most of the insidious laws are being used against a relatively small number of people, but with devastating consequences (up to and including imprisonment without charge or, in at least one obvious case, death). That's enough to stir up a lot of righteous indignation, but not enough for Joe Public to risk his own liberty defending the innocent victims. In a sense, this is a worse situation than widespread abuse, because while the consequences to the abused are no less serious, the people as a whole don't rise up to fight it, and it can continue for a long time and build up the victim count slowly.
I do not understand why the UK is allowing itself to deteriorate in such a fashion
It's trying not to. But you have to remember that the current administration was voted into an absolute majority in Parliament by only 22% of the electorate, and the party in power didn't even win the popular vote in England. Moreover, the Brown administration were appointed by party political people, contrary to a direct statement by the same party before the last general election that Tony Blair would serve for a full third term, and have absolutely no legitimate mandate whatsoever. The only reason these guys can do what they're doing is that our political system is utterly corrupt and non-representative, but short of violent revolution, there is little we can do about that until the next general election (which, at current rates of PR progress, will probably be announced some time next week).
What really scares me is that in the current political climate, with the only two opposition parties in England who get a significant number of votes both trying to prove themselves more impotent than the other, Brown may actually get in if he calls such an election, and then we're stuck with him for another five years. Here's hoping that those two opposition parties — both of whom have given concrete promises to repeal some of the more heinous legislation passed under Blair — get their acts together enough to at least reduce Labour to less than an absolute majority in Parliament.
As for the encryption keys - "Gee, I forgot it." Prove otherwise.
They don't have to. If you don't provide a key they believe exists, for any reason including the fact that it doesn't really exist or that you really have forgotten it, then you are automatically guilty under the RIPA. It's a bit of law to make those behind the USA PATRIOT Act proud — and our glorious government even wrote it before 9/11.
That depends. Next time you're talking to a hobbyist who has written a few useful utilities that they're willing to give away so others can benefit as well, and who has been kind enough to wrap them up in easy-to-use installers again purely so others can benefit, why don't you ask them how they'd feel about paying n×$100 for the privilege of giving away their own code?
If you're about to retort that OpenOffice.org is not a small-scale, hobbyist program, then please consider that the whole signing mechanism is dramatically reduced in value unless it is effectively universal.
Perhaps you place no value in security. That is the only way you can make the claim that you value code signatures (and signature verification) at $0.
There are so many non sequiturs in that argument, I don't know where to begin.
It is reasonable to argue that the signing mechanism does not bring a major improvement in security, for example because of the lack of universality mentioned above. This means the signing component isn't worth the asking price, not that security has no value.
It is also reasonable to argue that people are already paying for this mechanism, when millions of them shelled out for Windows, and therefore that Microsoft should provide it at no additional charge to developers if they feel it is an important factor contributing to Windows' security. This doesn't imply that the code signatures have no value, merely that developers should not have to pay for them. They are, after all, for the benefit of users rather than developers.
There seem to be other flaws in your argument, but either of the above seems to completely undermine it anyway.
Sorry, I should have been clearer about the anecdote. The intended point was that humans relatively frequently misguess whether an e-mail is spam when scanning the typical sender/subject/date/etc. index line, and consequently don't bother opening it and never see the content. How many people really go down their inbox mail by mail, opening and reading every one of the hundreds of spams they might receive in a day to make sure it's spam? And how many mass-delete everything that looks like spam, often without a second glance?
Given arbitrary time, of course humans will be more reliable at judging what they, subjectively, want to read. I'm talking about what tends to happen in reality, where the computer has the advantages of reading at near-instant speeds and never getting bored/tired, and where humans start to skip things or miss lines by mistake after a while.
Whenever you ask just a computer program to weed out spam , it will always be outwitted by average human intelligence.
Are you sure? Last time I saw any reasonably scientific study, human error was greater than machine error, at least in terms of false positives that result in lost mail if you give the human a typical scenario and set the anti-spam software to be typically aggressive.
If google is so damn loaded with money and that their search tech uses common user links, why not pay people/moderators for 'quality' links to information?
Because then you'd get the Open Directory Project, which IME is one of the most unpleasant, ungrateful, stuck up, anti-community organisations in the universe.
Yes. You can build a successful business with proprietary code and still show it to the world.
Indeed. I'm always somewhat amused when you see these company acquisitions in the software development business where the PHBs in the acquiring company talk about how wonderful a job they've done. It's always about two things: the customary tip of the hat to the "great staff" they've got, and then the patting each other on the back over all the IP they now own.
What most PHBs don't get is that the people usually have far more value than the code. People who've spent a lot of time solving certain type of problem could solve it again if they had too, probably much faster and with a better solution since they'll learn from their mistakes. However, as anyone who's ever joined an established and moderately large project can tell you, just having the source code without the people who are experts in how and why it does what it does has very limited value, and almost none at all unless the documentation is unusually good. I suspect that most companies could open up most of their code bases with very little real damage, if there was any worthwhile business reason for them to do so.
The problem with the whole area of tech patents evaluated by non-techie people is the classic teacher's dilemma: for those who understand, no explanation is necessary, while for those who do not understand, no explanation is possible.
Almost by definition, something is obvious if it is apparent without further explanation. However, like the many tests of "reasonableness" in law, obviousness is in the eye of the beholder and depends on context. Defining an accurate, repeatable, qualitative test that determines whether something is or is not obvious in general is impossible.
However, one realistic and credible test is whether other people in the field in question could sensibly be expected to "invent" the same thing in the same circumstances without much thought. I would argue that claiming a typical web developer wouldn't think of the idea to have a single click in a specific place perform an action is pretty insulting to the intelligence of web developers, not least because hyperlinks have been following this principle since before Amazon was a twinkle in Jeff Bezos's eye. Similarly, the idea of remembering user data to minimise repetitive data entry has been around in database world since many years before the web existed. This is drifting into prior art rather than obviousness, perhaps, but I suspect that's the best way to attack this particular lunacy. After all, you can't credibly argue that other people wouldn't think of the same thing in the same circumstances if many of them already did.
Except for games I've been able to entirely replace my windows install. I've not once had to go out and muck about in the console or installing software on my own.
I suspect that for many hobbyists, this may be true these days. The problem, for those who would like to see Linux as a viable competitor for Windows on the general home or business user's desktop, is that the Linux world just hasn't reached the same level in some key application areas yet.
Compare and contrast, if you will, the big names in document/graphics preparation:
Word vs. OpenOffice Writer, AbiWord, etc.
InDesign vs. Scribus
Photoshop vs. GIMP
Of course, there are also more niche but essential products in diverse fields from CAD to image rendering, where the Linux world doesn't really have anything to compete with the big boys yet.
Then we have games for the home user (assuming they don't just use a console). On Windows, we've had things like Supreme Commander, Oblivion, etc. over the past year or two. Meanwhile, the Linux world isn't even close to Windows classics like Total Annihilation, Deus Ex or the Baldur's Gate series, all of which were out years ago, and still relies on emulation to support games like these (if you can get your graphics card drivers to work and your favourite games are all supported, that is).
Sure, Linux has good Internet tools: there are decent web browsers, e-mail clients, and the like, and that's a major stepping stone. There's also the LAMP stack for developing useful database applications, which is another important tick on the list. And it has increasingly respectable media support (though some sort of consolidation in this area is desperately needed, as is out-of-the-box support for things like digital cameras and camcorders that use proprietary Windows software to get the pics/vids off the hardware and into a standard format on the hard drive). But until there are serious document/graphics systems for business users (I'm not even going to enter into discussions about why the above-mentioned are not serious as far as professionals are concerned; we've had those discussions many times before) and serious games for the home market, Linux will never be a viable competitor for Windows in the eyes of many users, no matter how good the operating system itself may get. And that's just competing: to win, you need to have killer apps that aren't available on Windows, and right now there isn't a single one of those.
Of course, this is not an unassailable problem. While I call it as I see it for the relative quality and power of the Linux apps of today, I also see that with the right project leadership, the OSS model has the potential to bridge all of these gaps relatively quickly. The irony of this whole situation, coming back to the topic at hand, is that Microsoft is currently doing more to level the playing field than anything the Linux community could ever do, simply because it appears to be making Windows worse with each successive version. You just can't go around imposing unreliable operation and performance hits, both made worse due to DRM, and countless large updates to patch silly security holes on users forever. Sooner or later, karmic revenge will happen, and for my money, I think Vista is going to make that sooner rather than later.
So while they can't realistically abandon Vista at this stage, it might be smart for them to have a team working on a completely new approach in the background — new architecture, new programming models, new development practices, whatever it takes — with a view to producing a serious contender next time around. When you're the size of Microsoft, you get to survive one Big Mistake on the back of inertia and market forces, but probably not two in a row. They have a lot of smart developers at MS, and some very, very smart people working at Microsoft Research, but it's obvious that their current approach (probably at the business/management level more than anything technical) isn't working and they need to promote up some of those good people and try things a different way.
But one thing Microsoft does not do is treat developers poorly.
Of course they don't. Unless you program C++, that is (in which case you're not important enough to have all the IDE features the C# jocks get, even those you used to have ten years ago in VC6). Or real VB (before all the.Net cruft). Or you used Visual J# (before they killed the compiler and stranded the developers).
On reflection, the only developers Microsoft hasn't treated poorly in recent years are those using their latest, whizz-bang, lock-in technologies. Not so long ago, that meant VB. Today, it means.Net and the C# clones. Next year, who knows?
It's a shame, really, because Visual Studio is the best IDE in town on some counts: the debugger, for example. But Microsoft's increasingly predatory tactics of recent years aren't really doing them any favours with serious developers, and the peak of their power in the industry has passed. To take advantage of much of the good stuff in the last few Visual Studio versions, you have to be tying yourself into Microsoft platforms, no sane person running a long-term project would voluntarily do that today, and without those features Visual Studio really isn't that great.
If you believe that computers will ultimately possess high intelligence, then you had better prey they don't develop with the morality of the Dick Cheney and his neo-GOP friends. If so, the next day after the computers realize they don't need us and can defeat us will be the last day of mankind. We had better hope they develop with something more like the morality of Gandhi.
Indeed. I believe it was Gandhi who said, "I like your Christ. I do not like your Christians. Your Christians are so unlike your Christ." For a nation with such Christian traditions, the leaders the US elect sure don't act like they believe in Christian values, and even as someone who isn't religious by nature, I'd rather people respected values like "thou shalt not kill" wherever realistic.
And there's also an issue, if you're fighting real wars against real opponents, that bigger guns and better armour aren't always the most effective choices. In a FPS, carrying 50 rockets and a launcher might make you the baddest guy on the level, but in real life, it just makes you slow and an easy target. Ask people who've been on the front lines whether they'd rather have a light pack and mobility or a whole bunch of extra armour but only be able to move literally at a crawl, and I imagine you'll get pretty consistent answers.
Despite the feel-good BS, "cooperation" does not usually result in an optimal solution. If a single person can handle the task, you'll get a much better final product than giving it to a team.
Sure, that can be true, but then I have to ask you two questions. I'm talking specifically about people on the software development path here, but I suspect analogous arguments hold for sysadmins too.
Firstly, for how many real projects does any approach truly give an optimal solution? How would we know what the optimal solution was ahead of time, anyway?
Secondly, how many real projects can be fully completed by a single person, within a realistic business time frame, and including all the related work that doesn't involve direct design and coding?
I don't for an instant dispute that a single great developer can be far more effective at the design and coding than a group of several average developers. Indeed there is plenty of research that supports this position. But — and this is where my distinction between helpful gurus and liabilities comes in — the work usually isn't going to be worth anything either way if no-one else can understand it, maintain the code later, write the accompanying user manuals and technical documentation, devise and run suitable higher-level tests, and so on. A good developer who can also communicate effectively with colleagues to achieve these things is a great asset, to be sure, but a rock star who can do the same technical things as the good developer but can't work with others is often a liability in the real world regardless of their technical expertise.
Even your use of "rock star", or the more negative "prima donna", betrays the reality of ths situation... A dozen decent studio musicians/singers don't replace one Jimi Hendrix or Sarah Brightman.
Perhaps. That's why I don't really like the term "rock star" in this context. Still, consider this: for most truly great musical performances, the lead is but one part of a whole cast and crew that create the overall effect. They have the name you remember, but if they couldn't sing or play with an orchestra or backing group, they didn't have good people on the lighting, the musical director was incompetent, or any other link in the chain broke, the great performance wouldn't happen no matter who the star was.
The most "fun" work environment for the worker is one of unstructured cooperation where there are no rules.
That sounds like it ought to be true, but IMHO it isn't. I think IT mainly attracts three kinds of people, and if you look at what drives them, it's never really that.
Firstly, you have those who are only in it for the money. They probably took some university course just so they could work in IT, and they probably aren't very good at their job. Most of them don't get very far, because their attitude is entirely selfish, and the only motivator they have is making as much money as possible from doing as little real work as possible. In their minds, they'll have fun later, when they're rich.
Then you have the "journeyman" developers and sysadmins: those who are happy to work in a well-paid industry, but basically see it as just another job. These people represent the largest proportion of the industry, IME. They are typically competent but unexceptional in their skill and aptitude, and approach their jobs with a reasonably professional attitude. The best motivator for these people, IME, is simply to let them get on with their job: give them clear instructions about what needs to be done, and some relevant background information if they're the kind of person who likes to see how they fit into the bigger picture, and then just get out of the way and let them do their work. These people typically recognise the value of good organisation, and respect strong but flexible leadership. They don't go to work to have fun, but they will find their work environment most pleasant this way and rarely demand more.
Finally, you have the guru types. Often, these are the guys who got into IT because they enjoy the field. If they took a university course they enjoyed or they get paid well, that's almost incidental, and just a bonus on top of having a job where they enjoy the work. These guys know their subjects inside out. The big variable — and the thing that separates the gurus who are great people to have in your group from the gurus who are liabilities — is how well these guys do things outside their own development or administration work.
Those who develop people skills, understand the business context for their work, cooperate with management, and give constructive input to these areas from the point of view of the IT guy, tend to go far, though they tend to stick to a technical path rather than moving into management. Motivation for these guys often comes from seeing a good result from their work, and they will work in whatever way seems best to achieve that goal. Again, this isn't usually unstructured cooperation; on the contrary, IME these guys are the ones most likely to want good processes in place, and to appreciate readily whether existing processes are helping or getting in the way. Often, these guys also value honest recognition when they produce good work, and like to know that when they make constructive suggestions they are being listened to.
Of course, you also get the gurus who want to have everything their own way. These are the guys who want their own office and to work in their own style. They want full-time ownership of the code they write (not that it matters since no-one else can understand it anyway) or the final say over any changes to their networks. These guys probably are motivated by unstructured work, but cooperation is a word that doesn't enter their vocabulary. Frankly, you're better off hiring a couple of less egotistical, less demanding, and far more pleasant and constructive journeyman types anyway than you would be getting stuck with one of these guys, who seem to be known as "rock star programmers" in trendy blogs.
So I don't think unstructured cooperation is really fun for any of the major types of IT guy. The good ones tend to appreciate enough structure to do an effective job, while the bad ones will cooperate only as far as is necessary to get what they want anyway, and often would prefer to stay under the radar and just do things their own way. Constructive anarchy doesn't really work for either group.
Who's paying this guy to harass you? Find out what agency he works for and have your VP give his VP a call.
If only it were that easy. Unfortunately, I'm in the UK, and neither the agencies nor the company I work for are big enough here for that sort of executive-level backroom chat.:-(
Slashdot Mirror
I have yet to hear a serious argument for why the world will be injured by behaving as if there is an ozone or climate problem (if there is not), and so I just don't understand why anyone ever makes this argument.
Well, that one's easy. If there is no real problem, but we still restrict doing things that we think are causing that non-existent problem, then we reduce quality of life. We choose modes of transport for people and goods that take longer or cost more to run, or avoid the journeys altogether. We rely on less efficient means of generating power. We restrict the use of otherwise beneficial devices that emit certain chemicals.
This isn't to say that I disagree with your basic point. It's simply that there is a significant downside to going all eco-friendly in terms of quality of life, at least in the short term until our economic model and technological progress can compensate.
(As it happens, I am somewhat sceptical about claims that the world is suddenly going to end because of global warming. Lots of people are suddenly very sure about this, because all these eminent scientists suddenly agree it's true. And yet, most of them didn't for decades beforehand, and no particular new evidence has been found. The current political climate is more about politics than climate. This is a different issue, though.)
You're right about the hardware support. I have been planning to move my home PC to dual boot with Linux since forever: I've been leaving separate hard disk partitions free for this purpose for years. But I never have actually installed Linux on my main home machine, because every time I come to look at it and do the research, I find showstopping issues with some piece of hardware or other.
I don't think that's the biggest obstacle to widespread Linux adoption, though. In fact, the real problem with Linux from the point of view of average home or office users has nothing to do with Linux itself. It is simply that, as TFA suggests, the applications just aren't there for serious users. To get people to shift away from the Windows platforms they're familiar with, Linux must offer better applications, yet there is not one "killer app" for Linux. Many of the best mass market OSS software is also available for Windows, particularly on the programming and server software front where Linux has traditionally been strong. For end users, there are commercial offerings on Windows as good or much better than almost anything on Linux.
The really silly thing is that a lot of this is actually caused by the community-driven OSS model that prevails in Linux world, which admits the kind of politics that would be squished by senior management in a traditional, commercial software development company. Your average end user doesn't care about GPL2 vs. GPL3. He doesn't need OpenOffice to try and be an MS Office clone, because he's got MS Office. He doesn't care about your open standard calendar support in your mail software, he just wants to connect to his corporate Exchange server. He doesn't care that Firefox is just following W3C recommendations in how it renders the page, when the page looks wrong in Firefox but right in IE.
This isn't to say that none of these things matters. To you and me and those who would like to see a better world, the technical details and open standards are important, and for some of us, perhaps the free software philosophy is too. But the bottom line is that the end user doesn't care. He just wants a system that can help him to do his work, relax at home, or whatever. As long as Linux doesn't have the same level of key application support that Windows has, and some "killer app" alternatives that are substantially better than what is available on Windows, it will never be the "year of Linux on the desktop" no matter how good the operating system itself may become, how easy it is to install, how pretty the widgets are in the GUI, or how many geeks object to the de facto standards and vendor lock-in that prevail in the Windows world.
It's a solved problem if you're a smart programmer sitting down to write a program. It isn't a solved problem if you need a simple rich client and somehow want to get out of doing it yourself :-)
Fair point. I'm definitely talking about the programming models and design techniques here, not the specific implementations, which I agree are sometimes amazingly poor for such a big, fast-evolving industry. For what it's worth, I think this applies to programming language design generally, not just in the particular area of concurrency.
That's what I normally do when I need multithreading for throughput; I write a nice high-level API that just happens to map perfectly to my needs, and I implement it using locks, mutexes, and conditions. It works, but it feels a bit like writing my own linked list implementation.
Yeah, I know what you mean. Whenever I start out on some new logging or unit testing code, I get that sinking "reinventing the wheel" feeling, too.
But then objectivity kicks in. This is not the same as rewriting a linked list. We have programming techniques that let us express our wish to reuse generic linked list code with a single line of new code. Linked lists are neat, self-contained entities, readily generalised, and easily understood in isolation. The kinds of frameworks we're talking about here, for things like multithreading, logging and testing, aren't there yet: they still spread through your new code, taking up residence like a well-worn sofa, and just about as hard to adapt or remove if you later decide you want to do things in a slightly different way.
When we have developed tools to abstract this complexity away, so that using these aspects of the code is really just a one-liner as well, then I will agree with you about having a collection of useful "off the shelf" libraries. But until the effort to use the library is substantially less than the effort to just build the necessary functionality in using the basic APIs, and the power of the libraries is substantially higher than what you get with those raw APIs, I don't think we'll reach the point where bringing in a multithreading framework is a no-brainer the way that reusing a linked list is today. I look forward to the day when that happens, because it will make life easier for many programmers, but from what I've seen, the kinds of libraries we're talking about aren't quite there yet.
This is the basis of the disagreement. My desktop has plenty of power, but too often I see apps balk or become unresponsive because of poor handling of concurrency. Even popular, high-profile apps with lots of resources behind them occasionally suffer, and less-used apps can be quite horrible about chronically locking up for a few seconds as you go about your work.
Sure, but that has been the case for years. The delay isn't because of multiple cores or processors, it's because of kindergarten design mistakes in a certain kind of architecture, and it's been a solved problem for a long time.
What the serious people are talking about is taking advantage of multicore/multiprocessor hardware by parallelising time-consuming algorithms that have typically been specified in terms of a single thread until this point. This is where the hard problems are, and where the big gains are to be made.
I don't think those building blocks are what people are calling a framework in this case; they mean something higher-level and more concrete that has design implications for the rest of the system, rather than being moldable into any design. That's why there are so many of them. Consider the multiplicity of logging frameworks for C++, despite them all being made out of file handles and objects.
Sure. But again, that's looking at the easy part of the problem. Once you've worked out the general architecture you want to use, just adopt whatever APIs you need to support it. If you've made the right decisions up to that point, the specific choice of library doesn't much matter.
From what I've seen so far, a lot of these libraries are much like logging or unit testing frameworks: sure, you can use one, but it's almost as much effort as just incorporating the equivalent functionality in your design from scratch. I suspect you have to reach a substantially higher level of abstraction, perhaps serious message passing frameworks or transactional memory, to get much advantage over using pretty raw concurrency and synchronisation APIs with a simple wrapper layer.
Actually, according to copyright law in most places and glossing over the use of "stealing" for "copyright infringement", yes, making those mix tapes was technically illegal. This is one reason I believe places like Europe need something closer to US-style fair use exemptions for copyright, instead of the watered-down, half-hearted framework allowed under the EUCD.
If you read between the lines of the Gowers report in the UK, for example, it sounds a lot like his team concluded that this was justified, but felt that they could only explicitly advocate changes that weren't contrary to the overarching EU framework. Thus they proposed an exemption for format shifting (which, incidentally, the big record labels already publicly said they'd turn a blind eye to in the UK — how does that fit with the Sony lawyer's statement here?). However, they did not go as far as proposing what I would like to see: a more general private use exemption, where essentially once you've got legitimate access to some content for yourself, any convenience copies for personal use are OK (format shifting, back-ups, mix tapes, etc.) but broadcast or distribution to others is still against the rules without a suitable additional licence. It seems to me that this is entirely consistent with the basic principle of copyright, and the only harm it does to content providers is to screw those who want people to pay for the same thing multiple times based on legal technicalities.
I couldn't agree more.
Several of my favourite quotations come from H. L. Mencken, who once observed that "The trouble with fighting for human freedom is that one spends most of one's time defending scoundrels. For it is against scoundrels that oppressive laws are first aimed, and oppression must be stopped at the beginning if it is to be stopped at all." The problem here, of course, is that even in these early stages, it's not just scoundrels who are being caught in the net.
Have you ever known anybody to say: "There are just too many girls to choose from, I guess I'll go hide in the basement."?
Have you never heard the expression "too much love will kill you"? Never been in (or seen) a situation where someone is torn between a relationship with one person and with another, when they genuinely care for both?
The results of such a dilemma are usually very unpleasant for the losing party, and all too often don't work out for the others either because there's that nagging doubt about whether the eventual choice was the right one. People can put off making that choice for a long time, just to avoid the sadness and doubts. And that's (usually) just with two alternatives.
Now, clearly a choice between programming libraries isn't going to have the same kind of emotional effect on a normal person. (I'd suggest that if it does for you, then you need to reevaluate your priorities in life!) But the basic situation is still the same: analysis paralysis, where you're so afraid of making the wrong choice that you don't commit to any approach at all.
I always find it amusing (in a sad kind of way) how people talk about Herb Sutter's "call to action" over this. It's not that I've got anything against Herb himself: he's a decent writer, an excellent speaker, and a guy who can use the word "expert" legitimately in areas like C++. But it's also not like he's the first guy to notice that modern desktop computer architectures have been heading for parallelisation rather than increased speed for several years now.
Despite being right in the thick of this culture shift myself — I'm sure I'm not the only one here who has been talking about this for a while, and is just seeing management catch up — I don't think this is going to be that big of a deal for most people. The harsh reality, for the buzzword-wielding consultants rubbing their hands with glee at a new programming approach they can hype up, is that most people just don't need all this.
Your average desktop PC is more than powerful enough for most things that most people do with it: Internet communications, writing documents, working with databases, shop floor software, and the like. As long as the operating system is reasonably smart about scheduling, the guys writing these common types of applications don't really have to know anything about multithreading, locking, message passing, and all that jazz. Similarly, your average mobile device has more than enough juice to dial another phone, write a quick e-mail, or capture a digital photo.
At the other end of the spectrum, serious servers (database, communications, whatever) have been dealing with parallel processing of many requests since forever. High-end systems doing serious maths (the guys modelling weather systems, say) have also been using massive parallelisation on their supercomputers for zillions of years now.
There is a gap between these different areas, which we might traditionally have called the "workstation" market: the guys doing moderate number crunching for CAD, scientific visualisation, simulations, and the like. Many modern games also fall into this classification. This market is ripe for a parallel processing revolution, because historically it hasn't followed this approach very much because the hardware wouldn't really take advantage of it, yet the extra power is genuinely useful. But I don't think this represents some huge proportion of the software development industry as a whole. The guys working in these areas tend to be pretty smart, and will no doubt adopt useful practices and conventions fairly quickly now that the hardware has reached the point that they are useful.
As to what those conventions are, I just don't buy the whole "choice overload" theory. There are relatively few basic models for parallel processing: for example, you can have no shared state and communicate only through message passing, or you can have shared state. In the latter case, you then have the question of how to make sure that the sharing is safe, which leads to lock-based or lock-free approaches. Funky toys like transactional memory run at a slightly higher level than this, but they are ultimately constructed from the same building blocks, and again there are only a small number of approaches at this level to consider.
I'm not familiar with all of those libraries mentioned in the story, but I'll bet that those three classifications (no shared state, shared state with explicit locking, shared state without explicit locks) probably cover the models used by most if not all of them. If you understand the trade-offs in those, you can produce a sensible design, and then the toolkit or framework you use to code it up is mostly just an implementation detail. Given that the trade-offs are pretty obvious and will often steer projects clearly in one direction, I don't think there's really that much to choose at all.
The problem is, laws like this aren't generally being used to abuse our population en masse (though of course they could be used to "justify" doing so in future). Right now, most of the insidious laws are being used against a relatively small number of people, but with devastating consequences (up to and including imprisonment without charge or, in at least one obvious case, death). That's enough to stir up a lot of righteous indignation, but not enough for Joe Public to risk his own liberty defending the innocent victims. In a sense, this is a worse situation than widespread abuse, because while the consequences to the abused are no less serious, the people as a whole don't rise up to fight it, and it can continue for a long time and build up the victim count slowly.
I do not understand why the UK is allowing itself to deteriorate in such a fashion
It's trying not to. But you have to remember that the current administration was voted into an absolute majority in Parliament by only 22% of the electorate, and the party in power didn't even win the popular vote in England. Moreover, the Brown administration were appointed by party political people, contrary to a direct statement by the same party before the last general election that Tony Blair would serve for a full third term, and have absolutely no legitimate mandate whatsoever. The only reason these guys can do what they're doing is that our political system is utterly corrupt and non-representative, but short of violent revolution, there is little we can do about that until the next general election (which, at current rates of PR progress, will probably be announced some time next week).
What really scares me is that in the current political climate, with the only two opposition parties in England who get a significant number of votes both trying to prove themselves more impotent than the other, Brown may actually get in if he calls such an election, and then we're stuck with him for another five years. Here's hoping that those two opposition parties — both of whom have given concrete promises to repeal some of the more heinous legislation passed under Blair — get their acts together enough to at least reduce Labour to less than an absolute majority in Parliament.
As for the encryption keys - "Gee, I forgot it." Prove otherwise.
They don't have to. If you don't provide a key they believe exists, for any reason including the fact that it doesn't really exist or that you really have forgotten it, then you are automatically guilty under the RIPA. It's a bit of law to make those behind the USA PATRIOT Act proud — and our glorious government even wrote it before 9/11.
Is $100 per year not a nominal fee?
That depends. Next time you're talking to a hobbyist who has written a few useful utilities that they're willing to give away so others can benefit as well, and who has been kind enough to wrap them up in easy-to-use installers again purely so others can benefit, why don't you ask them how they'd feel about paying n×$100 for the privilege of giving away their own code?
If you're about to retort that OpenOffice.org is not a small-scale, hobbyist program, then please consider that the whole signing mechanism is dramatically reduced in value unless it is effectively universal.
Perhaps you place no value in security. That is the only way you can make the claim that you value code signatures (and signature verification) at $0.
There are so many non sequiturs in that argument, I don't know where to begin.
It is reasonable to argue that the signing mechanism does not bring a major improvement in security, for example because of the lack of universality mentioned above. This means the signing component isn't worth the asking price, not that security has no value.
It is also reasonable to argue that people are already paying for this mechanism, when millions of them shelled out for Windows, and therefore that Microsoft should provide it at no additional charge to developers if they feel it is an important factor contributing to Windows' security. This doesn't imply that the code signatures have no value, merely that developers should not have to pay for them. They are, after all, for the benefit of users rather than developers.
There seem to be other flaws in your argument, but either of the above seems to completely undermine it anyway.
Sorry, I should have been clearer about the anecdote. The intended point was that humans relatively frequently misguess whether an e-mail is spam when scanning the typical sender/subject/date/etc. index line, and consequently don't bother opening it and never see the content. How many people really go down their inbox mail by mail, opening and reading every one of the hundreds of spams they might receive in a day to make sure it's spam? And how many mass-delete everything that looks like spam, often without a second glance?
Given arbitrary time, of course humans will be more reliable at judging what they, subjectively, want to read. I'm talking about what tends to happen in reality, where the computer has the advantages of reading at near-instant speeds and never getting bored/tired, and where humans start to skip things or miss lines by mistake after a while.
It's amazing, really.
Not really, you just aren't familiar with the secret techniques we Slashdot vets know and love.
Now, if you'll excuse me, I just have to go back in time and invent the Internet, again...
Whenever you ask just a computer program to weed out spam , it will always be outwitted by average human intelligence.
Are you sure? Last time I saw any reasonably scientific study, human error was greater than machine error, at least in terms of false positives that result in lost mail if you give the human a typical scenario and set the anti-spam software to be typically aggressive.
If google is so damn loaded with money and that their search tech uses common user links, why not pay people/moderators for 'quality' links to information?
Because then you'd get the Open Directory Project, which IME is one of the most unpleasant, ungrateful, stuck up, anti-community organisations in the universe.
Yes. You can build a successful business with proprietary code and still show it to the world.
Indeed. I'm always somewhat amused when you see these company acquisitions in the software development business where the PHBs in the acquiring company talk about how wonderful a job they've done. It's always about two things: the customary tip of the hat to the "great staff" they've got, and then the patting each other on the back over all the IP they now own.
What most PHBs don't get is that the people usually have far more value than the code. People who've spent a lot of time solving certain type of problem could solve it again if they had too, probably much faster and with a better solution since they'll learn from their mistakes. However, as anyone who's ever joined an established and moderately large project can tell you, just having the source code without the people who are experts in how and why it does what it does has very limited value, and almost none at all unless the documentation is unusually good. I suspect that most companies could open up most of their code bases with very little real damage, if there was any worthwhile business reason for them to do so.
But, but... It's so OBVIOUS!
The problem with the whole area of tech patents evaluated by non-techie people is the classic teacher's dilemma: for those who understand, no explanation is necessary, while for those who do not understand, no explanation is possible.
Almost by definition, something is obvious if it is apparent without further explanation. However, like the many tests of "reasonableness" in law, obviousness is in the eye of the beholder and depends on context. Defining an accurate, repeatable, qualitative test that determines whether something is or is not obvious in general is impossible.
However, one realistic and credible test is whether other people in the field in question could sensibly be expected to "invent" the same thing in the same circumstances without much thought. I would argue that claiming a typical web developer wouldn't think of the idea to have a single click in a specific place perform an action is pretty insulting to the intelligence of web developers, not least because hyperlinks have been following this principle since before Amazon was a twinkle in Jeff Bezos's eye. Similarly, the idea of remembering user data to minimise repetitive data entry has been around in database world since many years before the web existed. This is drifting into prior art rather than obviousness, perhaps, but I suspect that's the best way to attack this particular lunacy. After all, you can't credibly argue that other people wouldn't think of the same thing in the same circumstances if many of them already did.
Except for games I've been able to entirely replace my windows install. I've not once had to go out and muck about in the console or installing software on my own.
I suspect that for many hobbyists, this may be true these days. The problem, for those who would like to see Linux as a viable competitor for Windows on the general home or business user's desktop, is that the Linux world just hasn't reached the same level in some key application areas yet.
Compare and contrast, if you will, the big names in document/graphics preparation:
Of course, there are also more niche but essential products in diverse fields from CAD to image rendering, where the Linux world doesn't really have anything to compete with the big boys yet.
Then we have games for the home user (assuming they don't just use a console). On Windows, we've had things like Supreme Commander, Oblivion, etc. over the past year or two. Meanwhile, the Linux world isn't even close to Windows classics like Total Annihilation, Deus Ex or the Baldur's Gate series, all of which were out years ago, and still relies on emulation to support games like these (if you can get your graphics card drivers to work and your favourite games are all supported, that is).
Sure, Linux has good Internet tools: there are decent web browsers, e-mail clients, and the like, and that's a major stepping stone. There's also the LAMP stack for developing useful database applications, which is another important tick on the list. And it has increasingly respectable media support (though some sort of consolidation in this area is desperately needed, as is out-of-the-box support for things like digital cameras and camcorders that use proprietary Windows software to get the pics/vids off the hardware and into a standard format on the hard drive). But until there are serious document/graphics systems for business users (I'm not even going to enter into discussions about why the above-mentioned are not serious as far as professionals are concerned; we've had those discussions many times before) and serious games for the home market, Linux will never be a viable competitor for Windows in the eyes of many users, no matter how good the operating system itself may get. And that's just competing: to win, you need to have killer apps that aren't available on Windows, and right now there isn't a single one of those.
Of course, this is not an unassailable problem. While I call it as I see it for the relative quality and power of the Linux apps of today, I also see that with the right project leadership, the OSS model has the potential to bridge all of these gaps relatively quickly. The irony of this whole situation, coming back to the topic at hand, is that Microsoft is currently doing more to level the playing field than anything the Linux community could ever do, simply because it appears to be making Windows worse with each successive version. You just can't go around imposing unreliable operation and performance hits, both made worse due to DRM, and countless large updates to patch silly security holes on users forever. Sooner or later, karmic revenge will happen, and for my money, I think Vista is going to make that sooner rather than later.
So while they can't realistically abandon Vista at this stage, it might be smart for them to have a team working on a completely new approach in the background — new architecture, new programming models, new development practices, whatever it takes — with a view to producing a serious contender next time around. When you're the size of Microsoft, you get to survive one Big Mistake on the back of inertia and market forces, but probably not two in a row. They have a lot of smart developers at MS, and some very, very smart people working at Microsoft Research, but it's obvious that their current approach (probably at the business/management level more than anything technical) isn't working and they need to promote up some of those good people and try things a different way.
But one thing Microsoft does not do is treat developers poorly.
Of course they don't. Unless you program C++, that is (in which case you're not important enough to have all the IDE features the C# jocks get, even those you used to have ten years ago in VC6). Or real VB (before all the .Net cruft). Or you used Visual J# (before they killed the compiler and stranded the developers).
On reflection, the only developers Microsoft hasn't treated poorly in recent years are those using their latest, whizz-bang, lock-in technologies. Not so long ago, that meant VB. Today, it means .Net and the C# clones. Next year, who knows?
It's a shame, really, because Visual Studio is the best IDE in town on some counts: the debugger, for example. But Microsoft's increasingly predatory tactics of recent years aren't really doing them any favours with serious developers, and the peak of their power in the industry has passed. To take advantage of much of the good stuff in the last few Visual Studio versions, you have to be tying yourself into Microsoft platforms, no sane person running a long-term project would voluntarily do that today, and without those features Visual Studio really isn't that great.
Thanks. I guess you learn something new every day. :-)
I think my argument holds just as true either way, FWIW.
If you believe that computers will ultimately possess high intelligence, then you had better prey they don't develop with the morality of the Dick Cheney and his neo-GOP friends. If so, the next day after the computers realize they don't need us and can defeat us will be the last day of mankind. We had better hope they develop with something more like the morality of Gandhi.
Indeed. I believe it was Gandhi who said, "I like your Christ. I do not like your Christians. Your Christians are so unlike your Christ." For a nation with such Christian traditions, the leaders the US elect sure don't act like they believe in Christian values, and even as someone who isn't religious by nature, I'd rather people respected values like "thou shalt not kill" wherever realistic.
And there's also an issue, if you're fighting real wars against real opponents, that bigger guns and better armour aren't always the most effective choices. In a FPS, carrying 50 rockets and a launcher might make you the baddest guy on the level, but in real life, it just makes you slow and an easy target. Ask people who've been on the front lines whether they'd rather have a light pack and mobility or a whole bunch of extra armour but only be able to move literally at a crawl, and I imagine you'll get pretty consistent answers.
Despite the feel-good BS, "cooperation" does not usually result in an optimal solution. If a single person can handle the task, you'll get a much better final product than giving it to a team.
Sure, that can be true, but then I have to ask you two questions. I'm talking specifically about people on the software development path here, but I suspect analogous arguments hold for sysadmins too.
Firstly, for how many real projects does any approach truly give an optimal solution? How would we know what the optimal solution was ahead of time, anyway?
Secondly, how many real projects can be fully completed by a single person, within a realistic business time frame, and including all the related work that doesn't involve direct design and coding?
I don't for an instant dispute that a single great developer can be far more effective at the design and coding than a group of several average developers. Indeed there is plenty of research that supports this position. But — and this is where my distinction between helpful gurus and liabilities comes in — the work usually isn't going to be worth anything either way if no-one else can understand it, maintain the code later, write the accompanying user manuals and technical documentation, devise and run suitable higher-level tests, and so on. A good developer who can also communicate effectively with colleagues to achieve these things is a great asset, to be sure, but a rock star who can do the same technical things as the good developer but can't work with others is often a liability in the real world regardless of their technical expertise.
Even your use of "rock star", or the more negative "prima donna", betrays the reality of ths situation... A dozen decent studio musicians/singers don't replace one Jimi Hendrix or Sarah Brightman.
Perhaps. That's why I don't really like the term "rock star" in this context. Still, consider this: for most truly great musical performances, the lead is but one part of a whole cast and crew that create the overall effect. They have the name you remember, but if they couldn't sing or play with an orchestra or backing group, they didn't have good people on the lighting, the musical director was incompetent, or any other link in the chain broke, the great performance wouldn't happen no matter who the star was.
The most "fun" work environment for the worker is one of unstructured cooperation where there are no rules.
That sounds like it ought to be true, but IMHO it isn't. I think IT mainly attracts three kinds of people, and if you look at what drives them, it's never really that.
Firstly, you have those who are only in it for the money. They probably took some university course just so they could work in IT, and they probably aren't very good at their job. Most of them don't get very far, because their attitude is entirely selfish, and the only motivator they have is making as much money as possible from doing as little real work as possible. In their minds, they'll have fun later, when they're rich.
Then you have the "journeyman" developers and sysadmins: those who are happy to work in a well-paid industry, but basically see it as just another job. These people represent the largest proportion of the industry, IME. They are typically competent but unexceptional in their skill and aptitude, and approach their jobs with a reasonably professional attitude. The best motivator for these people, IME, is simply to let them get on with their job: give them clear instructions about what needs to be done, and some relevant background information if they're the kind of person who likes to see how they fit into the bigger picture, and then just get out of the way and let them do their work. These people typically recognise the value of good organisation, and respect strong but flexible leadership. They don't go to work to have fun, but they will find their work environment most pleasant this way and rarely demand more.
Finally, you have the guru types. Often, these are the guys who got into IT because they enjoy the field. If they took a university course they enjoyed or they get paid well, that's almost incidental, and just a bonus on top of having a job where they enjoy the work. These guys know their subjects inside out. The big variable — and the thing that separates the gurus who are great people to have in your group from the gurus who are liabilities — is how well these guys do things outside their own development or administration work.
Those who develop people skills, understand the business context for their work, cooperate with management, and give constructive input to these areas from the point of view of the IT guy, tend to go far, though they tend to stick to a technical path rather than moving into management. Motivation for these guys often comes from seeing a good result from their work, and they will work in whatever way seems best to achieve that goal. Again, this isn't usually unstructured cooperation; on the contrary, IME these guys are the ones most likely to want good processes in place, and to appreciate readily whether existing processes are helping or getting in the way. Often, these guys also value honest recognition when they produce good work, and like to know that when they make constructive suggestions they are being listened to.
Of course, you also get the gurus who want to have everything their own way. These are the guys who want their own office and to work in their own style. They want full-time ownership of the code they write (not that it matters since no-one else can understand it anyway) or the final say over any changes to their networks. These guys probably are motivated by unstructured work, but cooperation is a word that doesn't enter their vocabulary. Frankly, you're better off hiring a couple of less egotistical, less demanding, and far more pleasant and constructive journeyman types anyway than you would be getting stuck with one of these guys, who seem to be known as "rock star programmers" in trendy blogs.
So I don't think unstructured cooperation is really fun for any of the major types of IT guy. The good ones tend to appreciate enough structure to do an effective job, while the bad ones will cooperate only as far as is necessary to get what they want anyway, and often would prefer to stay under the radar and just do things their own way. Constructive anarchy doesn't really work for either group.
Who's paying this guy to harass you? Find out what agency he works for and have your VP give his VP a call.
If only it were that easy. Unfortunately, I'm in the UK, and neither the agencies nor the company I work for are big enough here for that sort of executive-level backroom chat. :-(