Dear colleagues,
A question please about the size of unikernel images:
I built mirage console "hello world" and the stripped disk image size is
3.2 MBytes. The runtime memory required to run the image is ~ 9 MBytes. Is
it possible to reduce futher the memory footprint?
Thanks much!
Wassim H.
_
Good read, thanks. I am not sure how you can deal with blocking events (timer,
read/write access to the disk). In that case, you are often "forced" to use
"''a Lwt.t" function. For instance, in [1] when reading the Git pack file I
need to pass a function to read uncompressed objects on disk (the
> On 13 Nov 2015, at 15:43, Daniel Bünzli wrote:
>
> Le vendredi, 13 novembre 2015 à 15:22, Hannes Mehnert a écrit :
>> I personally find the cohttp and TCP/IP code hard to read due to the use
>> of lots of functors / module abstractions, which are not necessarily
>> needed IMHO.
>
> Not only t
many modularisation abstractions can be overused - either coz excess
abstraction is done (there just aren't that many really different
types/cases of use) or coz it turns into an efficiency killer (or both) -
this showed up in a big open source router project called Xorp at berkeley
where they made
> Other than that the document feels like unstructured, poorly written [1],
> random rumblings.
>
Gosh!
___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/
Le vendredi, 13 novembre 2015 à 15:22, Hannes Mehnert a écrit :
> I personally find the cohttp and TCP/IP code hard to read due to the use
> of lots of functors / module abstractions, which are not necessarily
> needed IMHO.
Not only they are not needed, it's also the wrong way of handling this as
On Fri, Nov 13, 2015 at 04:22:49PM +0100, Hannes Mehnert wrote:
> On 11/13/2015 12:00, Daniel Bünzli wrote:
> > "Abstraction should be used where needed, keeping in mind that every
> > abstraction is a burden on the reader of the program (e.g. yourself in 5
> > years)."
> >
> > WTF. Abstraction
On 11/13/2015 12:00, Daniel Bünzli wrote:
> "Abstraction should be used where needed, keeping in mind that every
> abstraction is a burden on the reader of the program (e.g. yourself in 5
> years)."
>
> WTF. Abstraction is what makes it easier to read and understand the program.
> That's precis
The main performance thing is using an external SATA SSD, rather than
onboard flash which is usually extremely slow. The Cubietrucks are
reasonable for this.
Justin
On 12 November 2015 at 21:08, Stefan Xenon wrote:
> Hi!
> As a newbie I'm a bit confused which boards and CPUs work with
> MirageO
"Abstraction should be used where needed, keeping in mind that every
abstraction is a burden on the reader of the program (e.g. yourself in 5
years)."
WTF. Abstraction is what makes it easier to read and understand the program.
That's precisely what I see missing from people doing system progra
Hi Stefan,
I think the only thing that matters for an arm32 board is whether it
can run Xen. If it can, Mirage/Xen should work too. Cubieboard 2 and 3
are both known to work.
On 12 November 2015 at 21:08, Stefan Xenon wrote:
> Hi!
> As a newbie I'm a bit confused which boards and CPUs work with
I think protocols have 3 APIs - there's "lower level" i/o, there's "upper
level" i/o, and there's environmental (timers, resource exhausation or
relief, lie out of buffer or here's some more) - the APIs can be refined a
bit (init, config, and fire, read/write)
believe it or not, the OSI model is q
12 matches
Mail list logo
