Slashdot Mirror

Actually a good question, though it doesn't sound like it. But if I was hiring someone for my Windows network with some Linux background I'd probably like to know if he's an open source evangelist that'll try to push it everywhere even when not suitable, or a practically oriented person with a broad background that'll use the right tool for the job.

Well that was more or less what I meant, it's a good gambit to figure out the mindset of the candidate and that's just as important as technical ability. Evangelism isn't an issue, zealotry is and that arrogant and dismissive attitude cuts both ways but there are a couple of caveats. The GUI can often mask severe holes in an employees knowledge -- even monkeys can be trained to press buttons. Furthermore, employees are often more productive if you give them the freedom to use their preferred toolset and working method.

As Werner Vogels put it (quote from page 2)

Developers of our services can use any tools they see fit to build their services. Developers themselves know best which tools make them most productive and which tools are right for the job. If that means using C++, then so be it. Whatever tools are necessary, we provide them, and then get the hell out of the way of the developers so that they can do their jobs.

An example Virtual Machine Monitor without a Hypervisor is VMware Workstation: a small VMM is loaded to run the guest OS, but it is not complete enough to run the system - it has no task switcher, no memory manager, etc. The host OS acts as the hypervisor here - it is the source of highly-privileged operations unavailable to the guest. Another no-hypervisor VMM is KVM: KVM just runs a virtual machine, but depends on the rest of Linux to run more-privileged operations (and Linux itself becomes the hypervisor).

An example Hypervisor without a Virtual Machine Monitor is the partitioning software on high-end IBM, Sun, etc. machines, which allows you to physically partition the processors of the system into several actual machines - partitioned machiens with zero run-time interdependencies. Literally, a "hypervisor" is something which runs at a privilege level higher than the "supervisor" (the OS).

Hypervisors and virtual machine monitors have existed since the 1960s. Nobody confused the terms then. IBM started the confusion with a whitepaper"inventing" the type 1 / type 2 taxonomy to distinguish between 1960s-modern IBM mainframe architectures (low-end = hypervisor only, high-end = combination hypervisor/vmm) and the VMware Workstation architecture (host OS loads vmm; host OS acts as hypervisor). Note that VMware never claimed Workstation was a hypervisor! Certain communities (Wikipedia, the press) have accepted IBM's whitepaper as gospel truth, thus the prolifieration of "type 1" and "type 2" terms the past several years. (The same community has chosen to ignore academic research in the 1960s and 1996-2005 which used VMM and Hypervisor correctly.)

With apologies to many individuals who are legitimately using correct terminology, some poorly-informed folks are propagating the "type 2 hypervisor" meme to attempt to equate the abilities of a hypervisor/VMM with a VMM. This is not correct: a combination hypervisor/vmm ALWAYS can achieve better performance than separating the hypervisor and VMM - at the cost of creating a more complex hypervisor (ESX requires custom drivers; Xen requires a customized dom0). The fault for this confusion really rests with Intel: their VT extensions (and AMD's SVM response) have made it so easy to create a VMM that some folks are creating a VMM, then marketing it as a hypervisor in a misguided attempt to compete with existing hypervisors (ESX, Xen) instead of competing with other VMMs (VMware Workstation/Fusion, KVM, Parallels Desktop)

To understand what a VMM is, read this ACM article by Mendel Rosenblum. Academic research generally looks at VMMs (ways to run a virtual machine), not hypervisors (ways to run something with less privileges than the hypervisor). A rough gage of the quality of academic work is whether they manage say Hypervisor when they mean Virtual Machine Monitor. Anyone who thinks the two are the same is ignorant of the past ten years of academic research - and anyone ignorant of ten years of research is doing very poor-quality work. (Alas, Wikipedia chose to use the IBM whitepaper for defining terms instead of many years of published, peer-reviewed papers. Great "neutrality", folks!)

Now GPLv3 is trying to restrict people's use of HARDWARE as well.

Each TiVo DVR includes a secure microprocessor to which are delegated all public-key-based operations. This secure microprocessor contains a unique public/private key pair for each DVR, so that there are no global secrets for DVR authentication.

But you can't use your own code on TiVo's hardware. I'm afraid I'm in the camp that thinks GPL has no business telling people what they can and can't do on their hardware.

I eventually got onto their 'support' crew in Singapore who assured that their engineers were looking into it. I don't know how much looking you need to do to change a single entry on a DNS table from "nnn.nnn.nnn.42" to "nnn.nnn.nnn.38".

Oh and here's a single page version of TFA.

Amazon has already deployed such a system under the name of Mechanical Turk. The idea is that humans assist computers, providing what is cutely named artificial artifical intelligence. You can read more about the concept in an article that ACM Queue run on May 2006.
--
Code Quality: The Open Source Perspective

A dedicated programmer can write Fortran in any language.

(1) Ownership: instead of relying on short-term tactical projects and maintenance, create teams to 'own' each area of your business and technology - empower them to make business and technology decisions in that space (2) Measurement: setup appropriate metrics for your teams in their area - judge them against these metrics (a combination of business performance, system performance, uptime etc.) (3) Agile: don't stifle them with heavy methodology - rely on your teams to install the right processes for them: enough documentation, enough release management, enough testing - if they're not getting that right, a heavy process won't help them For an example of a company who IMHO get this right, take a look at this interview with Amazon CTO Werner Vogels: http://www.acmqueue.com/modules.php?name=Content&p a=showpage&pid=388

I do wonder why the FSF doesn't take the moral high-ground and let Linus be. If he doesn't want to be saved, why force him?

The FSF has consistently taken the high moral ground. They have always said that Torvalds (and everyone one else) has a right to use any license they choose for the software they write. The FSF even helped Tivo develop the loophole that let Tivo adhere the the letter of the GPLv2 while violating its spirit.

The FSF has not tried to force Torvalds to change to the GPLv3. What I object to is the anti-GPLv3 FUD that Torvalds launched. For example, he completely mis-read the anti-DRM provisions of an earlier version of the GPLv3 and claimed that everyone would have have to give up their private signing keys. This led to the "OMG! Linus can't sign his kernels" furore. Torvalds later retracted this outlandish claim but refrained from undoing the damage he had caused.

Torvalds choose to very publicly criticize the GPLv3 without first carefully reading it or sharing his criticism with the FSF (who would have helped him corrected his errors). The FSF did not respond in kind. How can you possibly interpret these events as the FSF relinquishing the high moral ground?

The FSF wants to alter its license and definition of freedom, not the other way around.

It is true that the FSF wants to fix the GPL now that the Tivo exploit is in the wild, but it is not true that the FSF is changing their definition of freedom. Their intent has been to make the GPL the least restrictive license possible that ensures that re-distributors are required to pass on the four freedoms. This has not changed.

Although I see the FSF point to OSS and Linus as 'heretics', ...

This is over the top and unfair. The FSF has not called OSS or Torvalds 'heretics'. Your saying so falsely implies that the FSF is filled with evangelical, religious-like zeal. If you have even a shred of evidence to support your absurd implication, please provide it.

Isn't it arrogant of the FSF to force compliance outside the realm of software?

I disagree with your premise that the FSF is trying to force compliance outside the realm of software. [We stopped beating our wives years ago.] The anti-tivoization clauses of the GPLv3 prevent re-distributors from using a combination of hardware and software to thwart the intent of the GPL by not passing on the freedoms they enjoyed when they received the software.

As I have said many times elsewhere, even the Tivo is hardware compatible with the GPLv3. In an ACM article, Jim Barton, the Tivo CTO says:

Each TiVo DVR includes a secure microprocessor to which are delegated all public-key-based operations. This secure microprocessor contains a unique public/private key pair for each DVR, so that there are no global secrets for DVR authentication.

Therefore, all Tivo need do to become GPLv3 compatible is to share the private key that belongs to each Tivo device with the owner of that device. No hardware changes would be required. Nor would this compromise their security model unless you insist that the Tivo owners are a security risk to their own machines (and no one else's).

How could anyone prevent the creation of a software license?

I would accomplish the task by spreading alarmist lies and misunderstandings about the license (many of which you, AlXtreme, have repeated in your most recent post). Then I would get a group of prominent and influential members of the FOSS community to sign a position paper outlining the "Dangers and Problems" with the new license, concluding with:

http://www.acmqueue.com/modules.php?name=Content&p a=printer_friendly&pid=453&page=2

Cleverly hidden on page 2 of 4 advertisement-riddled pages. You would think ACM could focus on the content with less distractions than other sites...guess not.

You know, some of the very old compilers sometimes know how to deal with this, but the more modern compilers have to learn and re-learn some of these things.... [W]hen the microprocessor was introduced, yes, system memory was only a few cycles away, and a demand-driven model of going after that memory and bringing data in that you needed was fine. The model that we have with Cell, which is more of a shopping list type of approach and you go out and you get the things that you need before you operate on them, is actually similar to what you had in the very early days, where also you may have had your main store on a spinning drum or something like that. And at that time, your processing capability, though much much much lower than it is today, was also significantly faster than your data store. So some of the techniques that people had to deal with those kinds of systems actually indeed come back into relevance right now, which is very interesting.

I found this one minute risk assessment tool to be particularly lucid on the issues.

This blog is cute with the "good agile, bad agile" gimmick. A more intelligent and insightful treatment of the issue can be found here, however.

http://www.acmqueue.com/modules.php?name=Content&p a=printer_friendly&pid=410&page=1

Will the future of HCI

Next

be a bunch of dialogs

Next

or will it be one page?

Next

Ahh, here we go:

http://www.acmqueue.com/modules.php?name=Content&p a=printer_friendly&pid=402&page=1

Regarding UML, this article from the same author is good :

http://www.acmqueue.com/modules.php?name=Content&p a=showpage&pid=130

Issue 8 of the ZeroC (creators of the Ice RPC protocol) linked to an active discussion in the rpc blogosphere on the legacy of CORBA, the fate of SOAP, and the age old problems of RPC:

* exhibit A: 11:40 Oct 3, 05: Mark Baker claims CORBA was a technical failure ( http://www.markbaker.ca/2002/09/Blog/2005/10/03#20 05-10-ws-corba )
* exhibit B: 15:38 Oct 3, 05: Steve Vinoski of Iona (leading CORBA vendor) begs to differ ( http://www.iona.com/blogs/vinoski/archives/000214. html ); a long discussion including Michi Henning from ZeroC ensues in the comments, including:

Even if I do define WSDL that is "loose" and makes lots of things optional, that typically doesn't help me. Loose coupling isn't of interest just for its own sake, but is of interest because people are looking for a way to solve the versioning problem: how can I evolve a distributed application over time without breaking everything that is deployed already, and without having to recompile and redeploy the universe? If I define WSDL that is "loose" to start with, so I get the loose coupling I so much need, by implication, I know in advance how the application will evolve: I put the "loose" bits in the WSDL definitions where I expect future variation in the data. But real life doesn't work that way. None of us is prescient and, as a rule, what makes the versioning problem so hard is that we *don't* know how an application will evolve in the future. In other words, people who say that I can solve the problem by writing "loose" WSDL are kidding themselves: the real world is not cooperative enough for this to work.

* Michi Henning

It's odd that CORBA should end up being sidelined by most of its original supporters, in favour of a supposedly simpler and cheaper system that ends up being frantically complicated (well over 100 related specifications, and counting) and far more expensive. But that's business for you!

* Tom Welsh

* exhibit C: 23:05 Oct 13, 05: Ted Neward discovers and enters the discussion ( http://blogs.tedneward.com/CommentView,guid,070274 e8-ccfd-4ebd-87b5-494564c39b77.aspx )

And here is another prediction: once people get over their current fixation with loose coupling, they will finally realize that, to get loose coupling, I don't need loose type systems that throw away compile-time type safety, and I don't need support at the protocol level at horrendous cost in performance. All I need is intelligent system design, a middleware that offers a workable implementation of multiple interfaces (check out Ice facets), and domain-specific standardization. With that, I get type safety, flexibility, and performance.

* Michi Henning

* exhibit D: 17:32 Oct 22, 05: Ken Horn comments on the issue ( http://kendes.blogspot.com/2005/10/loose-coupling- corba-vs-ws.html )

Links

* PEPt - An Architecture for Adaptable Remoting Systems ( http://haroldcarr.net/pept/ )
* YAML ( http://www.yaml.org/ )
* A Conversation with Roger Sessions and Terry Coatta ( http://www.acmqueue.com/m

Whereas in software, the requirements absolutely change (often by orders of magnitude) over time...It was always frustrating that the system I was developing had no requirements document and once it was written it changed every day.

That turns out to not be the case. Any competent Unix admin can handle several systems. In large installations, it's common for a small admin group to handle hundreds of Unix and/or Linux systems. In the last survey I saw, the ratio of Windows admins to systems was 1:10. I'm not sure I completely buy into that, as I know of a couple of sites where it's more like 1:70 or 1:80, and I don't operate in the Windows world much. Maybe some surveys reflect the fact that there are more small installations running Win than *ix?

But *ix definitely lends itself to large ratios. If you think Google, Amazon, much of Wall Street, etc., would run it if this weren't the case, you are in error.

MS Hotmail would surely qualify as a large Win installation, wouldn't it? We're talking tens of thousands of machines.

OK, now see http://www.theregister.co.uk/2002/11/21/ms_paper_t outs_unix/ for the situation there in 2002. Now it's all Win, and for a look at what it's currently like to admin, see http://www.acmqueue.com/modules.php?name=Content&p a=showpage&pid=353

Short answer is that less than 100 people admin it. A very high ratio.

The evidence shows either environment can run at high ratios, *if* you have the talent on hand, though *ix has a longer and better history in this area.

And finally, (opinion only) my take is that it's somewhat easier to find highly talented *ix admins. You may have to pay them a bit more, but the business case for that depends on, naturally, the business.

Or maybe you're referring to the single-machine case, though that isn't really that common? Sorry--you're still incorrect. Common or not, I know of several such, where one admin handles the system. Usually on top of Win duties as, completely contrary to your post, this isn't even remotely a full time job for a single person.

I've trained several such. As expected, some get it very quickly, some don't. The ones that didn't tended to be the ones that were hostile to the idea at a fundamental level. In some cases, that stance turned out to be 'career limiting', as they say. The ones that stepped up to the plate tended to be rewarded. They also added another valuable skill to their portfolio--surely this is no bad thing, in these uncertain times?

We've learned over the years that there is incredible value in human-readable, text-based transmission protocols. Take a look at this ACM paper, for example.

Primarily, this value appears when debugging, when exploring, and when trying to do something new. The primary downside of this approach is performance. This means that `parseable, readable text versus efficient, compact binary' is usually an engineering tradeoff.

In the majority of cases, the computer is more than fast enough to handle the parsing, since, well, that's what computers do. What programmers generally do is the other stuff -- debugging, exploring, and trying something new. This often means that readable, parseable, text-based protocols are to be preferred.

Certainly, there is value in the idea of a `standard serialization system', but it's very easy to want to include everything. For example, look at any of the recent work on XML.

Ok!

ACM Queue did a nice interview with the Director of SETI@home and BOINC

http://acmqueue.com/modules.php?name=Content&pa=sh owpage&pid=313

Mars rovers use WindRiver VxWorks, probably version 5... who needs a BSOD when you have this little favorite "workQPanic: Kernel work queue overflow"... ugh.

check out http://acmqueue.com/modules.php?name=Content&pa=sh owpage&pid=227 , to be fair, these guys go above and beyond to try and prevent glitches and random crappola.

-j

This article http://acmqueue.com/modules.php?name=Content&pa=sh owpage&pid=209 covers the subject of VoIP security nicely

This article: http://acmqueue.com/modules.php?name=Content&pa=sh owpage&pid=53 includes a lot more info about the history of tivo, specifically in regard to how it relies on open source software

Neither Intel nor Motorola nor any other chip company understands the first thing about why that architecture was a good idea.
Just as an aside, to give you an interesting benchmark--on roughly the same system, roughly optimized the same way, a benchmark from 1979 at Xerox PARC runs only 50 times faster today. Moore's law has given us somewhere between 40,000 and 60,000 times improvement in that time. So there's approximately a factor of 1,000 in efficiency that has been lost by bad CPU architectures.

The myth that it doesn't matter what your processor architecture is--that Moore's law will take care of you--is totally false.

Who is the third?! Deaths always come in threes.

Well, we have a few candidates: Hunter S. Thompson?(Fear and Loathing in Las Vegas).

Or Sandra Dee(also known as Gidget)

Or Arthur Miller (Death of a Salesman, The Crucible)

FORTRAN?

SCO?

Delicious Delicacies?

Spreadfirefox.com?

The company project manager?

Why your project will fail:

1. Use of an inappropriate methodology.

2. Lack of customer involvement.

3. Lack of formal project management practices.

4. Dissimilarity to previous projects

5. Project complexity

6. Requirements volatility.

Is Your Development Project a Sinking Ship?

The one-minute risk assessment tool

All that said, though, I still think it's an ugly language. And I think there is something to be said for a programming language preventing some bad programming habits simply by not having any support for GOTOs.

Also digressing a little from my first point...did anybody else notice the irony of an article about clarity in programming posting code examples in a .jpg?

From page 5 of the article:http://www.acmqueue.com/modules.php?name=C ontent&pa=showpage&pid=247&page=5

Like Inglish speling, XML is here to stay.

OTOH, there's nothing stopping anyone from writing their own code generator/translator, which is all this really is. Also, for prior examples, the Clipper compiler was extremely modifiable (and that was 2 decades ago). Heck, you can even use make, cat, and a couple of perl scripts to translate plain english into code if you're REALLY desparate to find something to do with your time. (Anyone remember the dBASE code generators? Ugh!)

Check out There's No Such Thing as a Free (Software) Lunch. It's summarized as: What every developer should know about open source licensing and written by a General Counsel at Wasabi, an Open Source company.

5 x 3.0 = 15.2 ??? Huh?
6 x 1.9 = 11.6 ??? What?
7 x 1.1 = 7.4 ?????
9 x 0.8 = 7.3 ?

At least they got 1 x 1.7 and 3 x 1.5 right. Sheesh, no wonder projects fail if that's the sort of mathematical skills people have.

. . . but my B.S. meter exploded. This is the kind of shit that business programs spew out.

It wouldn't have been so bad, just a qualitative redeclaration of the obvious, but then they had THE formula for risk assessment. Also, keep in mind, this study was based on interviews with IT executives, not staff or customers. I'm sure that this simply consisted of a series of bubble-sheets with a few questions on it.

I guess, this is better than nothing, but, as noted in earlier posts, common-sense is still twice as good.

Wow, for people who like books like Tufte's The Visual Display of Quantitative Information, these guys produced a really good graphic as part of their article:

http://www.acmqueue.com/figures/issue019/tiwana3.g if

1. The set of all risk drivers (name of each sphere).
2. The relative importance of each risk driver (size of each sphere).
3. How much influence a manager has on each risk driver (horizontal position of each sphere).
4. The relative risk of each driver (proximity of sphere to center of graph).
5. The relative type of risk that each driver represents (vertical position of each sphere).

That's an extremely elegant graph that conveys all of the most important points of the paper, and would still manage to fit legibly on a small card.

Mmmm, mmmm! Nothing satisfies like elegant design!

The tragedy here is that the big marketing machines have brainwashed the gullible, desperate, and ignorant into believing that UML is a silver bullet. As a result, diagram making robots are often directed to generate their beautiful models for unknown stakeholders and with unknown value to create the illusion of progress (Gravitational Fever: Afflictees measure progress by the weight of their UML diagrams).This is just one scenario of many that gives the UML a black eye.

Let's face it, any tool can be misused and abused. People need to learn to use the UML where it is valuable to do so, at the proper level of detail, and with appropriate completeness. When used under the proper adult supervision, the UML truly can be a valuable communication and visualization tool with which to improve productivity as opposed to killing it.

Is Death by MDA Fever around the bend?

That's a very interesting take on some specific issues one often comes across when trying to use UML.

Personal experience has shown that some of the features of UML are useful. We often use class diagrams to help new developers on the project get quickly up to speed. The class relationship information, which is what they need, is more densely represented in UML than as code. That said, we rarely use most of the other artefacts. Pseudocode and flowcharts often seem to work much better.

When it comes down to it, UML is sometimes a useful communication tool, but that's about the extent of it. When you have a bunch of developers who communicate better in some other way, you use that instead.

to parent, for decent info on VoIP check out: http://www.acmqueue.com/modules.php?name=Content&p a=showpage&pid=203 that article is one of many on that site. sno

Standards should be based on real experience, not on committee designs. Perhaps an even better way of putting this would be: "If you haven't actually lived with the design proposed as a standard, don't adopt it." The best way to establish whether a specification is real or not is to implement several alternative interfaces. In fact, the IETF has set just such a rule for itself, holding that no standard can be created unless there already are at least two interoperating implementations. Similarly, computer users who hope to use a particular standard to leverage their buying power should always take care to test their systems on two separate implementations before deciding whether to link their fates to that standard. The Grid community in particular would be well advised to adopt just such a discipline before wedding itself to standards that define its future. Unfortunately, the Grid software is being done in a monopolistic fashion by a few government labs and not in the fashion of IETF.

Hi, editor of Queue here. I hope my reply get's modded up :)

I must say that I strongly disagree with your characterization of Queue. We *emphatically* disallow any product pitching whatsoever -- in fact, it's a requirement (as stated on our authors FAQ) that articles focus on *problems* not solutions (i.e. technologies, not products). You cite two articles, and I think you're analysis of them is unfair.

First off, we always invite technologists to write our articles, not journalists, not marketers. Why? Because we feel technologists are the only ones who can credibly speak to other technologists -- and can specifically rise above the marketing fray we believe is all-too-common in technology publishing. The TCP/IP Offload and the search/IT articles you mention are both written by experts in their fields. Surprise, they also work for companies that match their area of expertise. You don't want us to get a hard-drive expert to talk about C++ buffer overruns do you?

Second, as readers will see in both articles (and I of course invite any and all scrutiny) neither of the articles you mention promote specific products. And, where they discuss any given approach to a problem, they also point out shortcomings with those approaches, and problems left to be solved. I hardly call this self-serving editorial (pointing out problems w/you own area of technology doesn't tend to sell more products!)

Lastly, all of our articles are reviewed, not by advertisers or even hordes of editors -- but by other technologists. If an article smacks of cheerleading, it's rejected. And believe me, we reject plenty. In fact, you should also know that the vast majority of are articles are *solicited* by Queue from authors, and not the other way around.

I hope you'll take another look at Queue - we think it's *more* objective than any other technology publication out there!

Edward Grossman, Editor, Queue

Hi, editor of Queue here. I hope my reply get's modded up :)

I must say that I strongly disagree with your characterization of Queue. We *emphatically* disallow any product pitching whatsoever -- in fact, it's a requirement (as stated on our authors FAQ) that articles focus on *problems* not solutions (i.e. technologies, not products). You cite two articles, and I think you're analysis of them is unfair.

First off, we always invite technologists to write our articles, not journalists, not marketers. Why? Because we feel technologists are the only ones who can credibly speak to other technologists -- and can specifically rise above the marketing fray we believe is all-too-common in technology publishing. The TCP/IP Offload and the search/IT articles you mention are both written by experts in their fields. Surprise, they also work for companies that match their area of expertise. You don't want us to get a hard-drive expert to talk about C++ buffer overruns do you?

Second, as readers will see in both articles (and I of course invite any and all scrutiny) neither of the articles you mention promote specific products. And, where they discuss any given approach to a problem, they also point out shortcomings with those approaches, and problems left to be solved. I hardly call this self-serving editorial (pointing out problems w/you own area of technology doesn't tend to sell more products!)

Lastly, all of our articles are reviewed, not by advertisers or even hordes of editors -- but by other technologists. If an article smacks of cheerleading, it's rejected. And believe me, we reject plenty. In fact, you should also know that the vast majority of are articles are *solicited* by Queue from authors, and not the other way around.

I hope you'll take another look at Queue - we think it's *more* objective than any other technology publication out there!

Edward Grossman, Editor, Queue

Hi, editor of Queue here. I hope my reply get's modded up :)

I must say that I strongly disagree with your characterization of Queue. We *emphatically* disallow any product pitching whatsoever -- in fact, it's a requirement (as stated on our authors FAQ) that articles focus on *problems* not solutions (i.e. technologies, not products). You cite two articles, and I think you're analysis of them is unfair.

First off, we always invite technologists to write our articles, not journalists, not marketers. Why? Because we feel technologists are the only ones who can credibly speak to other technologists -- and can specifically rise above the marketing fray we believe is all-too-common in technology publishing. The TCP/IP Offload and the search/IT articles you mention are both written by experts in their fields. Surprise, they also work for companies that match their area of expertise. You don't want us to get a hard-drive expert to talk about C++ buffer overruns do you?

Second, as readers will see in both articles (and I of course invite any and all scrutiny) neither of the articles you mention promote specific products. And, where they discuss any given approach to a problem, they also point out shortcomings with those approaches, and problems left to be solved. I hardly call this self-serving editorial (pointing out problems w/you own area of technology doesn't tend to sell more products!)

Lastly, all of our articles are reviewed, not by advertisers or even hordes of editors -- but by other technologists. If an article smacks of cheerleading, it's rejected. And believe me, we reject plenty. In fact, you should also know that the vast majority of are articles are *solicited* by Queue from authors, and not the other way around.

I hope you'll take another look at Queue - we think it's *more* objective than any other technology publication out there!

Edward Grossman, Editor, Queue

I didn't see anybody else link to Green Density. Look at the Compute Density (Mflops/sf) of Green Destiny+ vs ASCI Q from back in 2002. It makes a very strong case for using a ton of weaker more effcient processors. I don't think I'd want a bunch of p4 or athlons sitting under my desk making the room super hot.

Of course "Which would you rather use to plow a field, two strong oxen or 1024 chickens" - Seymore Cray (or something along those lines)

This article entitled My programming language made me do it kinda says it all really..

it's called bigotry.

ACM Queue open source article on bigotry: article

Wow ... like this is anything new? This concept has been around, and you can implement it in many ways (pen carries, direct pda-to-pda transfer, or network transfer in the background). I'm not sure how this is different.

AAO has nailed it. it's all about the "Honor" system that they created - it's an implicit anti-idiot feature which all but eliminates the morons that show up online when you are playing.

BF1942 would be a great game, if it weren't for all the tards that show up. they need the honor system - AFAIK AAO is the first and only online game that uses it. here is why this is important.

the gaming industry is HUGE - it is bigger than the theaterical movie theater industry (ie. revenue from ALL movies in ALL theaters in the US doesn't even come close to touching the revenue from GAMES.)

in fact, if you combine all the money made by LOTR it's about the same as Madden Football (and that game didnt cost a zillion dollars to make)

anyway - so dis the US army all you want, but they are paving the way for serious anti-idiot game play.

w00t.

You obviously didn't RTFA, because the Author proposes
"Typically, the installation program determines the level of performance and configures in-game options accordingly. Gamers can then choose to alter those choices at the expense of performance or quality."
here, then continues to elaborate this scenario.

That page is annoying. For anyone on low-bandwidth or Lynx connections, here is the printer/human-friendly page.

Page 1 Page 2 Page 3 Page 4 Page 5 Page 6 Page 7

Page 1 Page 2 Page 3 Page 4 Page 5 Page 6 Page 7