On 11/24/2016 08:19 AM, Martin Kühne via arch-general wrote:
> This whole sandboxing and containerisation idiocy is such a pain. Oh
> look, the apps are not secure, the apps sometimes crash. But you know
> what, let's take a high level approach, because we're such great
> managers. Let's NOT make b
On Sat, Nov 26, 2016 at 3:23 PM, Maarten de Vries
> To my knowledge, makechrootpkg uses systemd-nspawn, which means it is
> already using a container. Reproducible builds will need quite a bit more
> work than simply using containers though.
I only meant reproducible environment but failed to ma
On Sat, Nov 26, 2016 at 3:23 PM, Bennett Piater wrote:
>> Another very useful case would be using containers as a chroot replacement
>> for having clean (only what's in the recipe), reproducable build environments
>> for building arch packages. It would also allow installing makedeps only in
>> th
On Sat, Nov 26, 2016 at 3:23 PM, Maarten de Vries wrote:
>
>
> On 26 November 2016 at 15:08, Carsten Mattner via arch-general
> wrote:
>>
>>
>> Another very useful case would be using containers as a chroot replacement
>> for having clean (only what's in the recipe), reproducable build
>> environ
On 26 November 2016 at 15:08, Carsten Mattner via arch-general <
arch-general@archlinux.org> wrote:
>
> Another very useful case would be using containers as a chroot replacement
> for having clean (only what's in the recipe), reproducable build
> environments
> for building arch packages. It woul
> Another very useful case would be using containers as a chroot replacement
> for having clean (only what's in the recipe), reproducable build environments
> for building arch packages. It would also allow installing makedeps only in
> the container/chroot or make cross-compilation easier to manag
On Fri, Nov 25, 2016 at 7:01 PM, pelzflorian (Florian Pelz)
wrote:
> Containers are an attempt to solve multiple issues. One is being a
> replacement for bundles. When people sell and distribute a proprietary
> app/game, they presumably want it to run on as many systems as possible
> with as littl
Containers are an attempt to solve multiple issues. One is being a
replacement for bundles. When people sell and distribute a proprietary
app/game, they presumably want it to run on as many systems as possible
with as little effort as possible. Having to rely on volunteer
maintainers is not good, n
Am 24.11.2016 um 15:19 schrieb Martin Kühne via arch-general:
> This whole sandboxing and containerisation idiocy is such a pain. Oh
> look, the apps are not secure, the apps sometimes crash. But you know
> what, let's take a high level approach, because we're such great
> managers. Let's NOT mak
On Thu, Nov 24, 2016 at 03:19:49PM +0100, Martin Kühne via arch-general wrote:
> This whole sandboxing and containerisation idiocy is such a pain.
Containers are useful — I'm saying this as an admin with 10 years of
experience. Having semi-isolated controlled environments for testing, building,
ju
On Thu, Nov 24, 2016 at 08:41:12PM +0100, SET wrote:
> >This whole sandboxing and containerisation idiocy is such a pain.
>
> This topic has gone generic, so here are my 2 cents : those who don 't trust
> an app should just avoid it, and not even look at it; no one is bound to use
> an app; don '
>This whole sandboxing and containerisation idiocy is such a pain.
This topic has gone generic, so here are my 2 cents : those who don 't trust an
app should just avoid it, and not even look at it; no one is bound to use an
app; don 't contain, use something else.
--
> On 24 Nov 2016, at 15:19, Martin Kühne via arch-general
> wrote:
>
> This whole sandboxing and containerisation idiocy is such a pain.
I totally agree. Sandboxing and containerisation is no cure for bad code. When
you have a leaking pipe, you shouldn't simply but a bucket below it to keep
This whole sandboxing and containerisation idiocy is such a pain. Oh
look, the apps are not secure, the apps sometimes crash. But you know
what, let's take a high level approach, because we're such great
managers. Let's NOT make better apps and a better stack by actually
writing better multimedia l
14 matches
Mail list logo
