5:07 a.m.
Hi,
does a storage best practise document for oVirt exist?
Some examples:
oVirt allows to extend an existing storage domain: Is it better to keep a
1:1 relation between LUN and oVirt storage domain?
If not, is it better to avoid adding LUNs to an already existing storage
domain?
Following the previous questions:
Is it better to have 1 Big oVirt storage domain or many small oVirt storage
domains?
There is a max num VM/disks for storage domain?
In which case is it better to use "direct attached lun" with respect to an
image on an oVirt storage domain?
Example:
Simple web server: ----> image
Large database (simple example):
- root,swap etc: 30GB ----> image?
- data disk: 500GB -----> (direct or image?)
Regards,
Stefano
9:40 a.m.
Hi,
Answer inline
On Thu, Jun 8, 2017 at 1:07 PM, Stefano Bovina <bovy89(a)gmail.com> wrote:
> Example:
> Simple web server: ----> image
> Large database (simple example):
> - root,swap etc: 30GB ----> image?
> - data disk: 500GB -----> (direct or image?)
> Regards,
> Stefano
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
Hi,
does a storage best practise document for oVirt exist?
Some examples:
oVirt allows to extend an existing storage domain: Is it better to keep a
1:1 relation between LUN and oVirt storage domain?
What do you mean by 1:1 relation? Between storage domain and the number of
LUNs the domain reside on?
If not, is it better to avoid adding LUNs to an already existing
storage
domain?
No problems with storage domain extension.
Following the previous questions:
Is it better to have 1 Big oVirt storage domain or many small oVirt
storage domains?
Depends on your needs, be aware to the following:
- Each domain has its own metadata which allocates ~5GB of the domain size.
- Each domain is being constatntly monitored by the system, so large number
of domain can decrease the system performance.
There are also downsides with having big domains, like less flexability
There is a max num VM/disks for storage domain?
In which case is it better to use "direct attached lun" with respect to an
image on an oVirt storage domain?
2:10 p.m.
Thank you very much.
What about "direct lun" usage and database example?
2017-06-08 16:40 GMT+02:00 Elad Ben Aharon <ebenahar(a)redhat.com>:
Hi,
Answer inline
On Thu, Jun 8, 2017 at 1:07 PM, Stefano Bovina <bovy89(a)gmail.com> wrote:
> Hi,
> does a storage best practise document for oVirt exist?
>
>
> Some examples:
>
> oVirt allows to extend an existing storage domain: Is it better to keep a
> 1:1 relation between LUN and oVirt storage domain?
>
What do you mean by 1:1 relation? Between storage domain and the number of
LUNs the domain reside on?
> If not, is it better to avoid adding LUNs to an already existing storage
> domain?
>
No problems with storage domain extension.
>
> Following the previous questions:
>
> Is it better to have 1 Big oVirt storage domain or many small oVirt
> storage domains?
>
Depends on your needs, be aware to the following:
- Each domain has its own metadata which allocates ~5GB of the domain size.
- Each domain is being constatntly monitored by the system, so large
number of domain can decrease the system performance.
There are also downsides with having big domains, like less flexability
> There is a max num VM/disks for storage domain?
>
>
> In which case is it better to use "direct attached lun" with respect to
> an image on an oVirt storage domain?
>
>
> Example:
>
> Simple web server: ----> image
> Large database (simple example):
> - root,swap etc: 30GB ----> image?
> - data disk: 500GB -----> (direct or image?)
>
> Regards,
>
> Stefano
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
1:23 a.m.
Direct luns are disks that are not managed by oVirt. Ovirt communicates
directly with the lun itself, without any other layer in between (like lvm
in image disks).
The advantage of the direct lun is that it should have better performance
since there's no overhead of another layer in the middle.
The disadvantage is that you can't take a snapshot of it (when attached to
a vm, of course), can't make it a part of a template, export it, and in
general - you don't manage it.
Regards,
Idan
On Mon, Jun 12, 2017 at 10:10 PM, Stefano Bovina <bovy89(a)gmail.com> wrote:
Thank you very much.
What about "direct lun" usage and database example?
2017-06-08 16:40 GMT+02:00 Elad Ben Aharon <ebenahar(a)redhat.com>:
> Hi,
> Answer inline
>
> On Thu, Jun 8, 2017 at 1:07 PM, Stefano Bovina <bovy89(a)gmail.com> wrote:
>
>> Hi,
>> does a storage best practise document for oVirt exist?
>>
>>
>> Some examples:
>>
>> oVirt allows to extend an existing storage domain: Is it better to keep
>> a 1:1 relation between LUN and oVirt storage domain?
>>
> What do you mean by 1:1 relation? Between storage domain and the number
> of LUNs the domain reside on?
>
>> If not, is it better to avoid adding LUNs to an already existing storage
>> domain?
>>
> No problems with storage domain extension.
>
>>
>> Following the previous questions:
>>
>> Is it better to have 1 Big oVirt storage domain or many small oVirt
>> storage domains?
>>
> Depends on your needs, be aware to the following:
> - Each domain has its own metadata which allocates ~5GB of the domain
> size.
> - Each domain is being constatntly monitored by the system, so large
> number of domain can decrease the system performance.
> There are also downsides with having big domains, like less flexability
>
>> There is a max num VM/disks for storage domain?
>>
>>
>> In which case is it better to use "direct attached lun" with respect
to
>> an image on an oVirt storage domain?
>>
>
>>
>
>> Example:
>>
>> Simple web server: ----> image
>> Large database (simple example):
>> - root,swap etc: 30GB ----> image?
>> - data disk: 500GB -----> (direct or image?)
>>
>> Regards,
>>
>> Stefano
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
7:25 a.m.
On Wed, Jun 14, 2017 at 9:23 AM, Idan Shaby <ishaby(a)redhat.com> wrote:
Direct luns are disks that are not managed by oVirt. Ovirt
communicates
directly with the lun itself, without any other layer in between (like lvm
in image disks).
The advantage of the direct lun is that it should have better performance
since there's no overhead of another layer in the middle.
The disadvantage is that you can't take a snapshot of it (when attached to
a vm, of course), can't make it a part of a template, export it, and in
general - you don't manage it.
You can, of course, create a snapshot from the storage-side.
Y.
Regards,
Idan
On Mon, Jun 12, 2017 at 10:10 PM, Stefano Bovina <bovy89(a)gmail.com> wrote:
> Thank you very much.
> What about "direct lun" usage and database example?
>
>
> 2017-06-08 16:40 GMT+02:00 Elad Ben Aharon <ebenahar(a)redhat.com>:
>
>> Hi,
>> Answer inline
>>
>> On Thu, Jun 8, 2017 at 1:07 PM, Stefano Bovina <bovy89(a)gmail.com> wrote:
>>
>>> Hi,
>>> does a storage best practise document for oVirt exist?
>>>
>>>
>>> Some examples:
>>>
>>> oVirt allows to extend an existing storage domain: Is it better to keep
>>> a 1:1 relation between LUN and oVirt storage domain?
>>>
>> What do you mean by 1:1 relation? Between storage domain and the number
>> of LUNs the domain reside on?
>>
>>> If not, is it better to avoid adding LUNs to an already existing
>>> storage domain?
>>>
>> No problems with storage domain extension.
>>
>>>
>>> Following the previous questions:
>>>
>>> Is it better to have 1 Big oVirt storage domain or many small oVirt
>>> storage domains?
>>>
>> Depends on your needs, be aware to the following:
>> - Each domain has its own metadata which allocates ~5GB of the domain
>> size.
>> - Each domain is being constatntly monitored by the system, so large
>> number of domain can decrease the system performance.
>> There are also downsides with having big domains, like less flexability
>>
>>
>>> There is a max num VM/disks for storage domain?
>>>
>>>
>>> In which case is it better to use "direct attached lun" with
respect to
>>> an image on an oVirt storage domain?
>>>
>>
>>>
>>
>>> Example:
>>>
>>> Simple web server: ----> image
>>> Large database (simple example):
>>> - root,swap etc: 30GB ----> image?
>>> - data disk: 500GB -----> (direct or image?)
>>>
>>> Regards,
>>>
>>> Stefano
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
8:18 a.m.
This is a multi-part message in MIME format.
--------------37BC682EB9601C9224D7D9CF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
I normally assume that any performance gain from directlly attaching a
LUN to a Virtual Machine then using it in the traditional way are so
little to compensate the extra hassle to do that. I would avoid as much
as I cacn use it, unless it is for some very special reason where you
cannot do in any other way. The only real usage for it so far was
Microsoft SQL Server Clustering requirements.
Fernando
On 14/06/2017 03:23, Idan Shaby wrote:
Direct luns are disks that are not managed by oVirt. Ovirt
communicates directly with the lun itself, without any other layer in
between (like lvm in image disks).
The advantage of the direct lun is that it should have better
performance since there's no overhead of another layer in the middle.
The disadvantage is that you can't take a snapshot of it (when
attached to a vm, of course), can't make it a part of a template,
export it, and in general - you don't manage it.
Regards,
Idan
On Mon, Jun 12, 2017 at 10:10 PM, Stefano Bovina <bovy89(a)gmail.com
<mailto:bovy89@gmail.com>> wrote:
Thank you very much.
What about "direct lun" usage and database example?
2017-06-08 16:40 GMT+02:00 Elad Ben Aharon <ebenahar(a)redhat.com
<mailto:ebenahar@redhat.com>>:
Hi,
Answer inline
On Thu, Jun 8, 2017 at 1:07 PM, Stefano Bovina
<bovy89(a)gmail.com <mailto:bovy89@gmail.com>> wrote:
Hi,
does a storage best practise document for oVirt exist?
Some examples:
oVirt allows to extend an existing storage domain: Is it
better to keep a 1:1 relation between LUN and oVirt
storage domain?
What do you mean by 1:1 relation? Between storage domain and
the number of LUNs the domain reside on?
If not, is it better to avoid adding LUNs to an already
existing storage domain?
No problems with storage domain extension.
Following the previous questions:
Is it better to have 1 Big oVirt storage domain or many
small oVirt storage domains?
Depends on your needs, be aware to the following:
- Each domain has its own metadata which allocates ~5GB of the
domain size.
- Each domain is being constatntly monitored by the system, so
large number of domain can decrease the system performance.
There are also downsides with having big domains, like less
flexability
There is a max num VM/disks for storage domain?
In which case is it better to use "direct attached lun"
with respect to an image on an oVirt storage domain?
Example:
Simple web server: ----> image
Large database (simple example):
- root,swap etc: 30GB ----> image?
- data disk: 500GB -----> (direct or image?)
Regards,
Stefano
_______________________________________________
Users mailing list
Users(a)ovirt.org <mailto:Users@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/users
<http://lists.ovirt.org/mailman/listinfo/users>
_______________________________________________
Users mailing list
Users(a)ovirt.org <mailto:Users@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/users
<http://lists.ovirt.org/mailman/listinfo/users>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--------------37BC682EB9601C9224D7D9CF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>I normally assume that any performance gain from directlly
attaching a LUN to a Virtual Machine then using it in the
traditional way are so little to compensate the extra hassle to do
that. I would avoid as much as I cacn use it, unless it is for
some very special reason where you cannot do in any other way. The
only real usage for it so far was Microsoft SQL Server Clustering
requirements.<br>
</p>
<p>Fernando<br>
</p>
<br>
<div class="moz-cite-prefix">On 14/06/2017 03:23, Idan Shaby
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAO8Of3nQw=h5mBhYTWoM7i+5gs8rGY7NTRbqaY_rTBarbSh6Zw@mail.gmail.com">
<div dir="ltr">
<div>
<div>
<div>Direct luns are disks that are not managed by oVirt.
Ovirt communicates directly with the lun itself, without
any other layer in between (like lvm in image disks).<br>
</div>
</div>
The advantage of the direct lun is that it should have better
performance since there's no overhead of another layer in the
middle.<br>
</div>
The disadvantage is that you can't take a snapshot of it (when
attached to a vm, of course), can't make it a part of a
template, export it, and in general - you don't manage it.<br>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
Regards,<br>
</div>
Idan<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Mon, Jun 12, 2017 at 10:10 PM,
Stefano Bovina <span dir="ltr"><<a
href="mailto:bovy89@gmail.com" target="_blank"
moz-do-not-send="true">bovy89(a)gmail.com</a>&gt;</span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Thank you very much.
<div>What about "direct lun" usage and database
example?</div>
<div>
<div class="h5">
<div><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2017-06-08 16:40
GMT+02:00 Elad Ben Aharon <span
dir="ltr"><<a
href="mailto:ebenahar@redhat.com"
target="_blank"
moz-do-not-send="true">ebenahar@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">Hi,
<div>Answer inline<br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>On
Thu,
Jun 8, 2017 at 1:07 PM, Stefano
Bovina <span dir="ltr"><<a
href="mailto:bovy89@gmail.com"
target="_blank"
moz-do-not-send="true">bovy89(a)gmail.com</a>&gt;</span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>Hi,</div>
<div>does a storage best
practise document for oVirt
exist?</div>
<div><br>
</div>
<div><br>
</div>
<div>Some examples:</div>
<div><br>
</div>
<div>oVirt allows to extend an
existing storage domain: Is it
better to keep a 1:1 relation
between LUN and oVirt storage
domain?</div>
</div>
</blockquote>
</span>
<div>What do you mean by 1:1 relation?
Between storage domain and the
number of LUNs the domain reside
on? </div>
<span>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>If not, is it better to
avoid adding LUNs to an
already existing storage
domain?</div>
</div>
</blockquote>
</span>
<div>No problems with storage domain
extension.</div>
<span>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>Following the previous
questions:</div>
<div><br>
</div>
<div>Is it better to have 1 Big
oVirt storage domain or many
small oVirt storage domains?</div>
</div>
</blockquote>
</span>
<div>Depends on your needs, be aware
to the following:</div>
<div>- Each domain has its own
metadata which allocates ~5GB of the
domain size.</div>
<div>- Each domain is being
constatntly monitored by the system,
so large number of domain can
decrease the system performance.</div>
<div>There are also downsides with
having big domains, like less
flexability </div>
<span>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>There is a max num VM/disks
for storage domain?</div>
<div><br>
</div>
<div><br>
</div>
<div>In which case is it better
to use "direct attached lun"
with respect to an image on an
oVirt storage domain? </div>
</div>
</blockquote>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div> </div>
</div>
</blockquote>
</span>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"><span>
<div dir="ltr">
<div><br>
</div>
<div>Example:</div>
<div><br>
</div>
<div>Simple web server:
----> image</div>
<div>Large database (simple
example):</div>
<div> - root,swap etc: 30GB
----> image?</div>
<div> - data disk: 500GB
-----> (direct or image?)</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>Stefano</div>
</div>
<br>
</span>______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org"
target="_blank"
moz-do-not-send="true">Users(a)ovirt.org</a><br>
<a
href="http://lists.ovirt.org/mailman/listinfo/users"
rel="noreferrer"
target="_blank"
moz-do-not-send="true">http://lists.ovirt.org/mailman<wbr...
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org"
moz-do-not-send="true">Users(a)ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.ovirt.org/<wbr>mai...
<br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Users@ovirt.org">Users@ovirt.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/users">http://...
</pre>
</blockquote>
<br>
</body>
</html>
--------------37BC682EB9601C9224D7D9CF--
2:56 a.m.
On Wed, Jun 14, 2017 at 4:18 PM, FERNANDO FREDIANI <
fernando.frediani(a)upx.com> wrote:
I normally assume that any performance gain from directlly attaching
a LUN
to a Virtual Machine then using it in the traditional way are so little to
compensate the extra hassle to do that. I would avoid as much as I cacn use
it, unless it is for some very special reason where you cannot do in any
other way. The only real usage for it so far was Microsoft SQL Server
Clustering requirements.
I tend to agree (from performance perspective), though I don't have numbers
to back it up. It probably doesn't matter that much.
There are however other reasons to use a direct LUN - use of storage-side
features, such as replication, QoS, encryption, compression, etc. that you
may wish to apply (or disable) per storage.
Also, there are some strange SCSI commands that some strange applications
need that require direct LUN and SCSI pass-through. Clustering (via SCSI
reservations is certainly the first and foremost but not the only one).
Y.
Fernando
On 14/06/2017 03:23, Idan Shaby wrote:
Direct luns are disks that are not managed by oVirt. Ovirt communicates
directly with the lun itself, without any other layer in between (like lvm
in image disks).
The advantage of the direct lun is that it should have better performance
since there's no overhead of another layer in the middle.
The disadvantage is that you can't take a snapshot of it (when attached to
a vm, of course), can't make it a part of a template, export it, and in
general - you don't manage it.
Regards,
Idan
On Mon, Jun 12, 2017 at 10:10 PM, Stefano Bovina <bovy89(a)gmail.com> wrote:
> Thank you very much.
> What about "direct lun" usage and database example?
>
>
> 2017-06-08 16:40 GMT+02:00 Elad Ben Aharon <ebenahar(a)redhat.com>:
>
>> Hi,
>> Answer inline
>>
>> On Thu, Jun 8, 2017 at 1:07 PM, Stefano Bovina <bovy89(a)gmail.com> wrote:
>>
>>> Hi,
>>> does a storage best practise document for oVirt exist?
>>>
>>>
>>> Some examples:
>>>
>>> oVirt allows to extend an existing storage domain: Is it better to keep
>>> a 1:1 relation between LUN and oVirt storage domain?
>>>
>> What do you mean by 1:1 relation? Between storage domain and the number
>> of LUNs the domain reside on?
>>
>>> If not, is it better to avoid adding LUNs to an already existing
>>> storage domain?
>>>
>> No problems with storage domain extension.
>>
>>>
>>> Following the previous questions:
>>>
>>> Is it better to have 1 Big oVirt storage domain or many small oVirt
>>> storage domains?
>>>
>> Depends on your needs, be aware to the following:
>> - Each domain has its own metadata which allocates ~5GB of the domain
>> size.
>> - Each domain is being constatntly monitored by the system, so large
>> number of domain can decrease the system performance.
>> There are also downsides with having big domains, like less flexability
>>
>>
>>> There is a max num VM/disks for storage domain?
>>>
>>>
>>> In which case is it better to use "direct attached lun" with
respect to
>>> an image on an oVirt storage domain?
>>>
>>
>>>
>>
>>> Example:
>>>
>>> Simple web server: ----> image
>>> Large database (simple example):
>>> - root,swap etc: 30GB ----> image?
>>> - data disk: 500GB -----> (direct or image?)
>>>
>>> Regards,
>>>
>>> Stefano
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
_______________________________________________
Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
3:20 a.m.
On Thu, Jun 8, 2017 at 4:40 PM, Elad Ben Aharon <ebenahar(a)redhat.com> wrote:
Hi,
Answer inline
On Thu, Jun 8, 2017 at 1:07 PM, Stefano Bovina <bovy89(a)gmail.com> wrote:
>
> Hi,
> does a storage best practise document for oVirt exist?
>
>
> Some examples:
>
> oVirt allows to extend an existing storage domain: Is it better to keep a
> 1:1 relation between LUN and oVirt storage domain?
What do you mean by 1:1 relation? Between storage domain and the number of
LUNs the domain reside on?
>
> If not, is it better to avoid adding LUNs to an already existing storage
> domain?
No problems with storage domain extension.
>
>
> Following the previous questions:
>
> Is it better to have 1 Big oVirt storage domain or many small oVirt
> storage domains?
Depends on your needs, be aware to the following:
- Each domain has its own metadata which allocates ~5GB of the domain size.
- Each domain is being constatntly monitored by the system, so large number
of domain can decrease the system performance.
What do you mean by "reducing system performance"? on hypervisor side
or manager side?
We're planning to move serveral TBs of vm, splitted in several SD of
1TB of size.
Do you suggest creating a big storage domain of several terabytes?
It would be easier also for our deployment scripts, but we're still
valuating if is a good choice.
There are also downsides with having big domains, like less
flexability
Exactly what i was thinking: how do i replace a component of a storage domain?
Luca
--
"E' assurdo impiegare gli uomini di intelligenza eccellente per fare
calcoli che potrebbero essere affidati a chiunque se si usassero delle
macchine"
Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)
"Internet è la più grande biblioteca del mondo.
Ma il problema è che i libri sono tutti sparsi sul pavimento"
John Allen Paulos, Matematico (1945-vivente)
Luca 'remix_tj' Lorenzetto, http://www.remixtj.net ,
<lorenzetto.luca(a)gmail.com>
2720
days inactive
2727
days old
7 comments
6 participants
participants (6)
-
Elad Ben Aharon -
FERNANDO FREDIANI -
Idan Shaby -
Luca 'remix_tj' Lorenzetto -
Stefano Bovina -
Yaniv Kaul