On Tue, Nov 28, 2017 at 10:25:37AM +, Daniel P. Berrange wrote:
On Tue, Nov 28, 2017 at 10:22:21AM +, Daniel P. Berrange wrote:
On Tue, Nov 28, 2017 at 08:43:54AM +0100, Martin Kletzander wrote:
> Just a quick note on what I've found out after I dedicated half day to go
> through the
On Tue, Nov 28, 2017 at 10:47:33AM +, Nir Soffer wrote:
On Tue, Nov 28, 2017 at 9:44 AM Martin Kletzander
wrote:
On Mon, Nov 20, 2017 at 04:57:56PM +, Daniel P. Berrange wrote:
>On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote:
>> On Mon, Nov 20,
On Tue, Nov 28, 2017 at 9:44 AM Martin Kletzander
wrote:
> On Mon, Nov 20, 2017 at 04:57:56PM +, Daniel P. Berrange wrote:
> >On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote:
> >> On Mon, Nov 20, 2017 at 03:25:33PM +, Daniel P. Berrange wrote:
> >>
On Tue, Nov 28, 2017 at 10:22:21AM +, Daniel P. Berrange wrote:
> On Tue, Nov 28, 2017 at 08:43:54AM +0100, Martin Kletzander wrote:
> > Just a quick note on what I've found out after I dedicated half day to go
> > through the tour of go and some other tutorials. The learning curve of Go
> >
On Tue, Nov 28, 2017 at 08:43:54AM +0100, Martin Kletzander wrote:
> On Mon, Nov 20, 2017 at 04:57:56PM +, Daniel P. Berrange wrote:
> > On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote:
> > > On Mon, Nov 20, 2017 at 03:25:33PM +, Daniel P. Berrange wrote:
> > > >
> > > >
On Mon, Nov 20, 2017 at 04:57:56PM +, Daniel P. Berrange wrote:
On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote:
On Mon, Nov 20, 2017 at 03:25:33PM +, Daniel P. Berrange wrote:
>
> I shouldn't have used the word "allocation" in my paragraph above. As
> you say, both
On Thu, Nov 23, 2017 at 11:32:26AM +0100, Michal Privoznik wrote:
> On 11/14/2017 06:27 PM, Daniel P. Berrange wrote:
> >
>
> This might be more tricky than one would initially think. What about
> tests for instance? In our test suite we rely heavily on mocking. For
> instance, virpcitest uses
On 11/14/2017 06:27 PM, Daniel P. Berrange wrote:
>
This might be more tricky than one would initially think. What about
tests for instance? In our test suite we rely heavily on mocking. For
instance, virpcitest uses virpcimock which reimplements kernel behaviour
for detach/attach of PCI
On 11/20/2017 09:25 AM, Daniel P. Berrange wrote:
When I worked in OpenStack it was a constant battle to get people to
consider enhancements to libvirt instead of reinventing it in Python.
It was a hard sell because most python dev just didn't want to use C
at all because it has a high curve to
On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote:
> On Mon, Nov 20, 2017 at 03:25:33PM +, Daniel P. Berrange wrote:
> >
> > I shouldn't have used the word "allocation" in my paragraph above. As
> > you say, both languages have similar needs around allocation. The difference
>
On Mon, Nov 20, 2017 at 03:25:33PM +, Daniel P. Berrange wrote:
On Mon, Nov 20, 2017 at 12:24:22AM +0100, Martin Kletzander wrote:
On Tue, Nov 14, 2017 at 05:27:01PM +, Daniel P. Berrange wrote:
[...]
> I don't have direct experiance in Rust, but it has the same kind of benefits
over
On Mon, Nov 20, 2017 at 12:24:22AM +0100, Martin Kletzander wrote:
> On Tue, Nov 14, 2017 at 05:27:01PM +, Daniel P. Berrange wrote:
>
> [...]
>
> > I don't have direct experiance in Rust, but it has the same kind of
> > benefits over
> > C as Go does, again without the downsides of
On Tue, Nov 14, 2017 at 05:27:01PM +, Daniel P. Berrange wrote:
[...]
I don't have direct experiance in Rust, but it has the same kind of benefits
over
C as Go does, again without the downsides of languages like Python or Java.
There
are some interesting unique features to Rust that can
On Fri, Nov 17, 2017 at 10:04:35AM -0600, Chris Friesen wrote:
> On 11/17/2017 06:37 AM, Daniel P. Berrange wrote:
> > On Fri, Nov 17, 2017 at 01:34:54PM +0100, Markus Armbruster wrote:
> > > "Daniel P. Berrange" writes:
> > >
> > > [...]
> > > > Goroutines are basically a
On 11/17/2017 06:37 AM, Daniel P. Berrange wrote:
On Fri, Nov 17, 2017 at 01:34:54PM +0100, Markus Armbruster wrote:
"Daniel P. Berrange" writes:
[...]
Goroutines are basically a union of the thread + coroutine concepts. The
Go runtime will create N OS level threads,
On Fri, Nov 17, 2017 at 01:34:54PM +0100, Markus Armbruster wrote:
> "Daniel P. Berrange" writes:
>
> [...]
> > Goroutines are basically a union of the thread + coroutine concepts. The
> > Go runtime will create N OS level threads, where the default N currently
> > matches
"Daniel P. Berrange" writes:
[...]
> Goroutines are basically a union of the thread + coroutine concepts. The
> Go runtime will create N OS level threads, where the default N currently
> matches the number of logical CPU cores you host has (but is tunable to
> other values).
On Thu, Nov 16, 2017 at 04:55:55PM -0500, John Ferlan wrote:
> On 11/14/2017 12:27 PM, Daniel P. Berrange wrote:
> > When libvirt was created, C was the only viable choice for anything aiming
> > to be
> > a core system library component. At that time 2005, aside from C there were
> > common
On 11/16/2017 03:55 PM, John Ferlan wrote:
On 11/14/2017 12:27 PM, Daniel P. Berrange wrote:
Part of the problem is that, despite Linux having very low overhead
thread spawning, threads still consume non-trivial resources, so we try to
constrain how many we use, which forces an M:N
On 11/14/2017 12:27 PM, Daniel P. Berrange wrote:
> The Problem(s)
> ==
First off I'll state I'm not opposed to considering adopting or
integrating a newer language. Still, I have my concerns, fears,
uncertainty, and doubts. In a world where one must "adapt or die", I'm
not opposed
On Thu, Nov 16, 2017 at 02:58:33PM +0100, Peter Krempa wrote:
> On Tue, Nov 14, 2017 at 17:27:01 +, Daniel Berrange wrote:
> > The Problem(s)
> > ==
>
> Note at first: This is a personal opinion. I'm not discrediting any
> advantages a different language might have in technical
On Tue, Nov 14, 2017 at 17:27:01 +, Daniel Berrange wrote:
> The Problem(s)
> ==
Note at first: This is a personal opinion. I'm not discrediting any
advantages a different language might have in technical sense.
I'm against this. Go is a utterly ugly language. It looks as the
On Wed, Nov 15, 2017 at 02:59:20PM +, Daniel P. Berrange wrote:
> On Wed, Nov 15, 2017 at 12:28:30PM +0100, Bjoern Walk wrote:
> > Why has there never been a truly satisfying standard library for C for
> > this kind of stuff? If such a project would exist, this wheel
> > re-inventing would be
As a point of reference, libguestfs started to allow OCaml in the
daemon this summer, so effectively you can now use OCaml to implement
libguestfs APIs. (I'm not suggesting libvirt should use OCaml).
Some points:
- We have a mixed C / OCaml daemon. The vast majority of the code is
still C
On Wed, Nov 15, 2017 at 12:28:30PM +0100, Bjoern Walk wrote:
> Daniel P. Berrange [2017-11-14, 05:27PM +]:
> > The Problem(s)
> > ==
> >
> > When libvirt was created, C was the only viable choice for anything aiming
> > to be
> > a core system library
Hello Daniel,
thank you for this interesting insight. The future-proof choice of
tools, especially programming languages, is certainly a problem that a
lot of project have to solve sooner rather then later. For projects that
are currently written in any non-memory-managed language, this issue is
The Problem(s)
==
When libvirt was created, C was the only viable choice for anything aiming to be
a core system library component. At that time 2005, aside from C there were
common choices of Java, Python, Perl. Java was way too heavy for a low level
system component, Python was
27 matches
Mail list logo