<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general">
    <title>gmane.comp.clustering.beowulf.general</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31567"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31566"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31565"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31564"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31563"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31562"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31561"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31560"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31559"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31558"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31557"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31556"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31555"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31554"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31553"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31552"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31551"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31550"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31549"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31548"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31567">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31567</link>
    <description>&lt;pre&gt;
Playing devil's advocate here, but am honestly interested to know:
Isn't there a tacit expectation that if you are moving tons of data 
really fast, it will be "memory intensive"?  Are you not moving that 
data from disk into memory first, and then doing a bit (or a lot) of 
work on it and dumping it back out to disk or dumping it completely?

Maybe I'm screwing up the definition of "memory intensive" though... 
(Does memory-bound == memory-intensive?  I think no, but could be wrong.)

Best,

ellis
&lt;/pre&gt;</description>
    <dc:creator>Ellis H. Wilson III</dc:creator>
    <dc:date>2013-05-17T14:16:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31566">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31566</link>
    <description>&lt;pre&gt;
[commercial horn tooting]

Penguin makes a 4U Supermicro chassis based ARM system.  24 bay chassis.

We make a 2 and 4U 24, a 4U 48, and 4U 60 bay Scalable chassis based ARM 
system based upon

There are a number of others as well.  All based in one way or another 
upon the Calxeda reference design.

We've got their booting integrated into our tiburon control bit (local 
disk booting for so many nodes is so 1990's :) ), and I believe Penguin 
has their booting integrated into their cloud software.

[/commercial horn tooting]

Observations on using them:  ARM chips are not fast.  They are great 
when you need *many* cpu cycles in a given volume, just don't expect 
these to be speed demons.  They aren't.  They make great web servers, 
wonderful mail servers ... everything the *aaS system folks need.  With 
enough units running in parallel you can attack [buzzword warning] big 
data problems with abandon [/buzzword warning].  They are terrific for this.

But they really aren't (in this incarnation anyway), HPC&lt;/pre&gt;</description>
    <dc:creator>Joe Landman</dc:creator>
    <dc:date>2013-05-17T14:01:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31565">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31565</link>
    <description>&lt;pre&gt;
http://www.boston.co.uk/solutions/viridis/faq.aspx

What is the price-range of the Viridis?

The approximate pricing for the Viridis platform is as follows:

A fully populated Viridis server – with 48 nodes and 24 drives – is around $50,000
The mid-range Viridis server – with 24 nodes and 24 drives – is around $30,000
The minimum configuration – with a single EnergyCard and four hard drives – costs around $10,000.

Uh, I don't think so.
_______________________________________________
Beowulf mailing list, Beowulf&amp;lt; at &amp;gt;beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
&lt;/pre&gt;</description>
    <dc:creator>Eugen Leitl</dc:creator>
    <dc:date>2013-05-17T14:00:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31564">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31564</link>
    <description>&lt;pre&gt;How about the Boston Viridis?

http://www.boston.co.uk/solutions/viridis/default.aspx

--
Prentice

&lt;/pre&gt;</description>
    <dc:creator>Prentice Bisbal</dc:creator>
    <dc:date>2013-05-17T13:46:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31563">
    <title>Re: /. Swedish data center saves $1 million a year using seawater for cooling</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31563</link>
    <description>&lt;pre&gt;&amp;lt;opinion&amp;gt;

Considering the quality and durability of modern computer components;
anyone using AC chillers to cool their DC could be considered somewhat
moronic.

&amp;lt;/opinion&amp;gt;

[When will | is it required for] computer manufacturers and DC's be
forced to comply with similar stringent emissions regulations applied
to the auto energy. I wonder how much energy DCs use in comparison to
domestic energy use and automotive....

I could search but I have only had 3 hours sleep. My various ploys to
avoid on call duty failed this time.

ta,

Andrew

On 17 May 2013 12:02, Eugen Leitl &amp;lt;eugen&amp;lt; at &amp;gt;leitl.org&amp;gt; wrote:
&lt;/pre&gt;</description>
    <dc:creator>Andrew Holway</dc:creator>
    <dc:date>2013-05-17T11:56:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31562">
    <title>/. Swedish data center saves $1 million a year using seawater for cooling</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31562</link>
    <description>&lt;pre&gt;
http://www.networkworld.com/news/2013/051613-swedish-data-center-saves-1-269868.html

Swedish data center saves $1 million a year using seawater for cooling

Collocation provider Interxion uses water pumped from the Baltic Sea to cool
its data centers

By James Niccolai, IDG News Service 

May 16, 2013 04:26 PM ET

IDG News Service - A data center in Sweden has cut its energy bills by a
million dollars a year using seawater to cool its servers, though jellyfish
are an occasional hazard.

Interxion, a collocation company in the Netherlands that rents data center
space in 11 countries, uses water pumped from the Baltic Sea to cool the IT
equipment at its facilities in Stockholm.

[ IN PICTURES: 10 of the world's coolest data centers ]


Credit: James Niccolai, IDG News Service

Lex Coors of Interxion describes his company's salwater cooling system at the
Uptime Institute Symposium.  The energy used to cool IT equipment is one of
the costliest areas of running a data center. Companies have traditionally
used b&lt;/pre&gt;</description>
    <dc:creator>Eugen Leitl</dc:creator>
    <dc:date>2013-05-17T10:02:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31561">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31561</link>
    <description>&lt;pre&gt;
Working real AI or personal immortality are quite useful, at least
for some people, I could imagine.


I dislike big systems, and be it only becase they're resource
intensive (and hence not exactly egalitarian computing). 
Unfortunately, a lot of very practical problems require quite 
massive resources, and preferably under everybody's desk
who would care to get one.
 

If you look at holistic approaches like http://www.openworm.org/
and http://www.si-elegans.eu/ these are quite easy to validate,
given a sufficiently diverse behaviour library. Markram is more
basic research in comparison, to obtain the parameters for 
the biologically accurate simulations.


It is pretty much limited, if your primary input is the annotated
connectome, at few nm resolution.
 

Well, at least it's 100% fully renewable juice.


Yes, both for my personal computing (mostly, just a few old boxes on
the Internet, less than kW total) and the dayjob I do that. I would 
gladly buy ARM cluster-in-a-rackmount, provided the price/perfor&lt;/pre&gt;</description>
    <dc:creator>Eugen Leitl</dc:creator>
    <dc:date>2013-05-17T06:42:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31560">
    <title>[hpc-announce] EURO-PAR 2013 WORKSHOPS: SECOND JOINT CALLFOR PAPERS</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31560</link>
    <description>&lt;pre&gt;[Apologies if you got multiple copies of this email. If you'd like to
opt out of these announcements, information on how to unsubscribe is
available at the bottom of this email.]
********************************************************************* 
**** EURO-PAR 2013 WORKSHOPS:  SECOND JOINT CALL FOR PAPERS 
********************************************************************* 

19th International European Conference on 
Parallel and Distributed Computing 

Euro-Par 2013 
Aachen, Germany 
August 26-30, 2013 
 &amp;lt;http://www.europar2013.org&amp;gt; http://www.europar2013.org 

**** SUBMISSION DEADLINES **** 

Workshop papers due: May 31, 2013, 23:59 AOE 

**** SCOPE OF THE CONFERENCE AND WORKSHOP PROGRAM **** 
Euro-Par is an annual series of international conferences dedicated to the
promotion and advancement of all aspects of parallel and distributed
computing. It covers a wide spectrum of topics from algorithms and theory to
software technology and hardware-related issues, with application areas
ranging from scienti&lt;/pre&gt;</description>
    <dc:creator>an Mey, Dieter</dc:creator>
    <dc:date>2013-05-08T17:24:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31559">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31559</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/05/13 01:55, Eugen Leitl wrote:


Depends on your timezone.. ;-)

cheers,
Chris (GMT +10)
- -- 
 Christopher Samuel        Senior Systems Administrator
 VLSCI - Victorian Life Sciences Computation Initiative
 Email: samuel&amp;lt; at &amp;gt;unimelb.edu.au Phone: +61 (0)3 903 55545
 http://www.vlsci.org.au/      http://twitter.com/vlsci

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlGVjfcACgkQO2KABBYQAh9HoACfR+y7RkMwYudNymfksMlkofFB
X98AnRDIXJ40mHcao4CLM2xn1zxWwfio
=YqnW
-----END PGP SIGNATURE-----
&lt;/pre&gt;</description>
    <dc:creator>Christopher Samuel</dc:creator>
    <dc:date>2013-05-17T01:55:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31558">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31558</link>
    <description>&lt;pre&gt;

On 5/16/13 9:50 AM, "Mark Hahn" &amp;lt;hahn&amp;lt; at &amp;gt;mcmaster.ca&amp;gt; wrote:



AN interesting concept.. Given the spheres don't pack super well, would
you, in the long run, be better off packing cubes or tetrahedrons or some
other 3d tile-able shape.

Could be a Kerr solution blackhole with angular momentum

Could be some thing more complex, for which you will need the computer to
figure it out.

&lt;/pre&gt;</description>
    <dc:creator>Lux, Jim (337C</dc:creator>
    <dc:date>2013-05-17T00:07:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31557">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31557</link>
    <description>&lt;pre&gt;
Or 3D chess (runs for cover)


&lt;/pre&gt;</description>
    <dc:creator>Joe Landman</dc:creator>
    <dc:date>2013-05-16T17:44:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31556">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31556</link>
    <description>&lt;pre&gt;
sure - such suggestions are pretty easy to put together, but they do not 
answer the question: should it be done, and at what cost?  I still think
they're really being used as a fig-leaf to cover the erection people get 
when imagining the "next-a-scale" facility.

simulations like this are extremely dubious in that they're fundamentally
limited by the quality of raw configuration data.  it is emphatically not 
clear that neuroscience is primarily limited by the scale of machines to 
run simulations.


even retail, fully-delivered rates here are half that.  but out of curiosity,
does your comment mean that you, for instance, buy arm clusters, or at least 
LV versions of x86 chips (and high-core, low-clock models), gold/platinum
PSUs, etc?  (or just do your compute in a location with cheaper power?)

regards, mark hahn.
&lt;/pre&gt;</description>
    <dc:creator>Mark Hahn</dc:creator>
    <dc:date>2013-05-16T17:37:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31555">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31555</link>
    <description>&lt;pre&gt;
weight (and 2d footprint) are purely linear, and not very interesting,
to me at least.  it's demonstrably possible (not hard) to do racks 
in 3d - and in fact doing so generally draws more attention to the 
macro-structure of the cluster anyway (including airflow, for instance.)


I think I'm actually making the opposite argument.  that at least for 
inter-unit networking, the topology for very scaled clusters needs to be
a 2 or 3d mesh.  if you're building a cluster laid out in 2d, as most are,
then there are scaling problems with any non-2d topology.  I love higher-
order fabrics (fat trees, hypercubes, dragonfly, kautz, etc), but they 
have a sweet spot in their scale, and the whole point of exascale seems 
to be to exceed all sweet spots.

within a "unit" (chassis, rack, take your pick), it's practical to exceed
the "consensual dimensionality" - especially since you get to use different 
materials (say, a backplane with a complex pattern of connections
implementing a 5d torus, etc).  inside the package,&lt;/pre&gt;</description>
    <dc:creator>Mark Hahn</dc:creator>
    <dc:date>2013-05-16T16:50:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31554">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31554</link>
    <description>&lt;pre&gt;

We already exist in 3d - racks. We limit rack heights due to weight already
(another item to add to your list of limits above).

I understand that you are arguing for 3d is silicon (or other substrate),
but there will still be a practical limit.

I saw some presentation a year or two ago that showed an exascale system as
a sphere with the switch complex in the center. It looked very 60s-ish,
proto-EPCOTish...



Shouldn't it be wormhole-based? The blackhole-based one will just destroy
the data, no?
&lt;/pre&gt;</description>
    <dc:creator>atchley tds.net</dc:creator>
    <dc:date>2013-05-16T16:33:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31553">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31553</link>
    <description>&lt;pre&gt;
Only in this universe

--
Doug



&lt;/pre&gt;</description>
    <dc:creator>Douglas Eadline</dc:creator>
    <dc:date>2013-05-16T16:28:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31552">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31552</link>
    <description>&lt;pre&gt;And I thought it was hard to hire Fpga software developers.  

Sent from my iPhone

On May 16, 2013, at 8:37 AM, "Joe Landman" &amp;lt;landman&amp;lt; at &amp;gt;scalableinformatics.com&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Lux, Jim (337C</dc:creator>
    <dc:date>2013-05-16T16:25:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31551">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31551</link>
    <description>&lt;pre&gt;

Yeah, if you're working with nm^3 bits you can only directly couple
to neighbor bits, whether primitive cubic or a closest packing.
FWIW, maximal refresh rate is ~100 PHz for such geometries
(but failure mode will be likely more plasma than corium).


It's pretty clear you have to lay down virtual traces in
crystalline hardware like http://people.csail.mit.edu/nhm/cc.pdf
Notice that you can get viral capsids to crystallize quite nicely,
and they definitely don't want that. So you can build a hierarchical
assembly that produces a macroscopic crystal, if you can do nice
DNA and/or protein tertiary structure design de novo.
 

What, it ain't even Friday yet?
&lt;/pre&gt;</description>
    <dc:creator>Eugen Leitl</dc:creator>
    <dc:date>2013-05-16T15:55:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31550">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31550</link>
    <description>&lt;pre&gt;
OK, I can see that.  to me, power is similar to a number of other issues, 
which provide extreme limits to scaling.  (power, reliability, net,
perhaps even storage and software complexity).  from a CS background,
these all have distressing O()-type complexity, so each is clearly
a hard limit at some scale, given some level of technology.

maybe I'm just more pessimistic ;)

I guess I did think the flops power versus even on-chip communication thing
was interesting.  but isn't the lesson to optimize for dataflow *and*
sometimes perform redundant computations?


anyone have an url on this topic?  fundamentally, I've always reasoned that 
since we exist in 3d, our networks need to be a 3d lattice at scale.
fighting power (flops, comm) seems like a noble, *engineering* fight,
but fighting our existence's dimensionality is silly...

yes, I would like to demo your new blackhole-based interconnect! ;)

regards, mark hahn.
&lt;/pre&gt;</description>
    <dc:creator>Mark Hahn</dc:creator>
    <dc:date>2013-05-16T15:45:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31549">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31549</link>
    <description>&lt;pre&gt;
[...]


"Quantum computing:  Because low level VHDL/Verilog is just not hard enough"



&lt;/pre&gt;</description>
    <dc:creator>Joe Landman</dc:creator>
    <dc:date>2013-05-16T15:37:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31548">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31548</link>
    <description>&lt;pre&gt;
We have to stop using fermions for computing and start using bosons. 
Talk about massively parallel ... Overlap those wavefunctions baby!

BTW:  I am actually not kidding about this, fermions provide an 
effective serialization of a particular data path, while bosons 
(photons) allow many simultaneous uses.  Combined with "quantum 
computing" (not D-Wave, but something ... er ... more ... quantum ... 
like ... thingy) where we can have "switches" in many states at once, 
and interacting with input (bosons) ...

Think optical fibre or cable for TVs.  Huge aggregate bandwidth, one 
small cable.  Bosons rule.  Fermions dribble.


&lt;/pre&gt;</description>
    <dc:creator>Joe Landman</dc:creator>
    <dc:date>2013-05-16T15:32:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31547">
    <title>Re: Pony: not yours.</title>
    <link>http://permalink.gmane.org/gmane.comp.clustering.beowulf.general/31547</link>
    <description>&lt;pre&gt;

That is doubtful. We got a one-time jump from accelerators (per the
slides).
&lt;/pre&gt;</description>
    <dc:creator>atchley tds.net</dc:creator>
    <dc:date>2013-05-16T15:24:23</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.clustering.beowulf.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.clustering.beowulf.general</link>
  </textinput>
</rdf:RDF>
