Re: Fedora/RedHat is moving is a similar direction

On 5 September 2015 at 15:02, Liam Proven <[email protected]> wrote:
> On 26 August 2015 at 22:24, Trans <[email protected]> wrote:
>> On Wed, Aug 26, 2015 at 10:09 AM, Sergio Tortosa Benedito
>> <[email protected]> wrote:
>>
>>> When I said standalone, I didn't mean that every single application
>>> must not need anything, there may be times where they may need other
>>> things (in cases like modular applications or servers), is just a
>>> simplification of the  bundle concept. How it's done it depends on
>>> those behind the project and the capabilites of the bundling system.
>>
>> I was reading a bit more about what they were planning
>> (https://wiki.gnome.org/Projects/SandboxedApps/Sandbox) and I can't
>> help but think this is all getting hell-a-complicated. It basically
>> feels as if they are trying to shoe horn Linux into a design it wasn't
>> really intended.
>
> It is complicated, yes. Because security is complicated, and
> BlackHats/crackers are willing to use complicated methods to
> compromise your machines.
>
>> Wouldn't it be a whole lot easier just to give each user their own
>> docker instance and isolate things that way?
>
> Er, WTF?

Sorry, keyboard trouble. That was sent unfinished. Apologies.

>> If a particular app needs
>> to be isolated, then give it its own user, and allow users access to
>> it via remote (e.g. Xclient, ssh, etc.)

No. That does not help at all. It literally contributes nothing at
all, *and* would get in the way.

Docker is a kind of standardized container for Linux.

Containers are a sort of virtual machine.

Current VMs are PC emulators for the PC: they virtualise the PC's
hardware, so you can run multiple OSes at once on one PC.

This is useful if you want to run, say, 3 different Linux distros,
Windows and Solaris on the same machine at once.

If you run lots of copies of the same OS, it is very inefficient, as
you duplicate lots of code.

Containers virtualise the OS instead of the computer. 1 OS instance, 1
kernel, but to the apps running on that OS, each app has its own OS.
Apps cannot see other apps at all. The virtualisation means that each
app thinks it is running standalone on the OS, with nothing else
installed.

This means that you can, say, run 200 instances of Apache on 1
instance of Linux, and they are all isolated. If one crashes, the
others don't. You can mix versions, have custom modules in one that
the others don't have, etc.

All without the overhead of running 200 copies of the OS.

Containerising apps is a security measure. It means that if, say, you
have a compromised version of LibreOffice that contains an exploit
allowing an attacker to get root, they get root in the container, and
as far as they can see, the copy of LibreOffice is the only thing on
the computer. No browser, no email, no stored passwords, nothing.

All within 1 user account, so that this can be done for multiple
users, side-by-side, even concurrently on a multiuser host.

It is nothing to do with user accounts; these are irrelevant to it.

Gobo's approach to bundling apps mainly just brings benefits to the
user: an easier-to-understand filesystem hierarchy, and apps that are
self-contained not spread out all over the filesystem. Nice, but not a
killer advantage. There's no big /technical/ advantage and it breaks
lots of things, which is why Gobo needs the gobohide kernel extension
and so on. It's also why Gobo has not really caught on.

But now, containers are becoming popular on servers. It's relatively
easy to isolate server apps: they have no GUI and often don't interact
much with other apps on the server.

Desktop apps are much harder to containerise. However, containerising
them brings lots of other advantages -- it could effectively eliminate
the differences between Linux distributions, forever ending the
APT-vs-RPM wars by making the packaging irrelevant, while delivering
much improved security, granularity, simplicity and more.

In theory all Gobo's benefits /at the app level/ (the OS underneath is
the same old mess) plus many more.

It looks like it might be something that will happen. It will have
some side-effects -- reducing the ease of interapp communication, for
instance. It mDocker is a kind of standardized container for Linux.

Containers are a sort of virtual machine.

Current VMs are PC emulators for the PC: they virtualise the PC's
hardware, so you can run multiple OSes at once on one PC.

This is useful if you want to run, say, 3 different Linux distros,
Windows and Solaris on the same machine at once.

If you run lots of copies of the same OS, it is very inefficient, as
you duplicate lots of code.

Containers virtualise the OS instead of the computer. 1 OS instance, 1
kernel, but to the apps running on that OS, each app has its own OS.
Apps cannot see other apps at all. The virtualisation means that each
app thinks it is running standalone on the OS, with nothing else
installed.

This means that you can, say, run 200 instances of Apache on 1
instance of Linux, and they are all isolated. If one crashes, the
others don't. You can mix versions, have custom modules in one that
the others don't have, etc.

All without the overhead of running 200 copies of the OS.

Containerising apps is a security measure. It means that if, say, you
have a compromised version of LibreOffice that contains an exploit
allowing an attacker to get root, they get root in the container, and
as far as they can see, the copy of LibreOffice is the only thing on
the computer. No browser, no email, no stored passwords, nothing.

All within 1 user account, so that this can be done for multiple
users, side-by-side, even concurrently on a multiuser host.

It is nothing to do with user accounts; these are irrelevant to it.

Gobo's approach to bundling apps mainly just brings benefits to the
user: an easier-to-understand filesystem hierarchy, and apps that are
self-contained not spread out all over the filesystem. Nice, but not a
killer advantage. There's no big /technical/ advantage and it breaks
lots of things, which is why Gobo needs the gobohide kernel extension
and so on. It's also why Gobo has not really caught on.

But now, containers are becoming popular on servers. It's relatively
easy to isolate server apps: they have no GUI and often don't interact
much with other apps on the server.

Desktop apps are much harder to containerise. However, containerising
them brings lots of other advantages -- it could effectively eliminate
the differences between Linux distributions, forever ending the
APT-vs-RPM wars by making the packaging irrelevant, while delivering
much improved security, granularity, simplicity and more.

In theory all Gobo's benefits /at the app level/ (the OS underneath is
the same old mess) plus many more.

It looks like it might be something that will happen. It will have
some side-effects -- reducing the ease of interapp communication, for
instance. It might break sound mixing, or inter-app copy-and-paste,
system browser/email/calender integration and some other things.

And systems will need a lot more hard disk space.

But possibly worth it overall.
ight break sound mixing, or inter-app copy-and-paste, system
browser/email/calender integration and some other things.

And systems will need a lot more hard disk space.

But possibly worth it overall.

>>> Btrfs is a *new* file system (just like EXT4, the one tipically used
>>> today), which features a lot of promising features (Copy On Write,
>>> Compression...) one of them being snapshots, which are pretty much
>>> like backups, with the advantage that btrfs only keeps differences not
>>> all the files several times. e.g: If I make a snapshot of a folder
>>> which have two files, then I can ask btrfs to make a snapshot out of
>>> that folder, so if I modify one file and add another one I can access
>>> the new folder and thanks to the snapshot the other one as well, the
>>> main difference from a standard copy is that btrfs will only keep the
>>> differences (the differences made to the file, and the new file) while
>>> the a standard copy would just have two copies of everything (ignoring
>>> if is duplicated or if it is not), you can even modify the snapshots
>>> just like any other folder. If you are curious I suggest you to search
>>> info about btrfs.
>>
>> But what bothers me about it is that it would lock users into Btrfs.
>> Is that what bothered you about it too? I mean, I get the advantage of
>> using delta's but the need not depend on a single file system.

Agreed, but this stuff might well need functionality that current FSs
don't deliver.

So maybe we'll get ext5 or Bcachefs or something *as well*.

>>> (I don't know much about docker so there's a possibility I'm wrong)
>>> Based on what I have read they serve the same purpose on a different
>>> level, images are barebones OSes, and provide a base upon which the
>>> application runs, runtimes are basically the same: a set of libraries
>>> provided by someone (GNOME, KDE ...) which include a set of libraries
>>> which application can base upon them, everything not included by these
>>> runtimes must be incorporated by the application.
>>
>> Ah, I see. Basically it is a snapshot of usr/ populated as needed for
>> a particular app.

More than that.

It is /the entire Linux filesystem/ -- *everything* -- populated as
needed for every app.

>>>> Oh, what did you think of the way they organized data, config and
>>>> cache directories all under a single per-application directory?
>>> Truth be told when I read this I jumped some parts, one of them the
>>> one telling this, so thank you for making me read that. I think it's a
>>> very good idea, though I wonder how will they manage having multiple
>>> versions of the same app with incompatible configs or other things, I
>>> like the ability to have more than directory (by changing the
>>> variables), as this gives (in an automatic and transparent way) a way
>>> of having more than one application profile.
>>
>> I think they expect the app to deal with config version differences. I
>> was somewhat concerned that it would be harder to manage, say, a
>> central `cache` location. Say if the admin wanted all cache to go to a
>> ram disk, for example.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: [email protected] • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: [email protected] • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
_______________________________________________
gobolinux-users mailing list
[email protected]
http://lists.gobolinux.org/mailman/listinfo/gobolinux-users