[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Address output-distance problems: (issue 563730043 by address@hidden

From: David Kastrup
Subject: Re: Address output-distance problems: (issue 563730043 by address@hidden)
Date: Fri, 13 Mar 2020 13:48:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Kevin Barry <address@hidden> writes:

>> The direction of this statement is correct, but the magnitude is not.  The
>> kernel is still provided by the host.   Getting a crash report can be
>> frustrating when the guest's behavior hinges on /proc features that the
>> host OS has configured appropriately for the host, not the guest.
>> Configurable security restrictions can make the debugging experience
>> different from one installation to another.  Et cetera.
> Yes it's true that containers are not completely safe from host
> configurations, but I didn't think talking about the 1% would help this
> discussion. If you think it makes pursuing this idea a waste of time then
> fair enough. David K doesn't like it either so I think it's time to let it
> go.

"is not convinced of various of the benefits this is touted with" is not
the same as "doesn't like it".  At the current point I don't see the
promised net wins that significantly depend on an abundance of
processing time being available either from volunteers or for pay.

The cost would become less if most of the test containers would not do
documentation builds.  However, where multiple versions of Ghostscript
are likely to cause trouble, that kind of restriction would not seem to
be optimal either.

So to end up a net win even given the restriction that we retain the
processing time of volunteers (since we are basically bound to blow the
free tiers of anything else with serious testing), our test setup would
need to get seriously more fine-grained.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]