Re: Fedora/RedHat is moving is a similar direction

2015-09-05 15:20 GMT+02:00 Liam Proven <[email protected]>:

> 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.

Even then, my opinion is that if we did this over Gobo, the result
would be an awesome distro, as Gobo clearly fits this type of systems.


> 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.

For my side as long as RAM usage does not grow much, I'm fine, I think
it's worth the effort if we can get more secure desktops.

>>>> 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*.

Bcachefs is interesting, would like to see if they ever get to compete with
EXT4 in direct performance, if they did then i'm sure lots of people
would change to it.
However, I must say BTRFS is not the only way to get this done, Limba,
for example,
uses overlayfs ( basically a sort of virtual filesystem which gets
mounted another one,
in an overlay fashion), making it fs independent, and unlike what may
be apparent it's
performance it's pretty much the same.

Now, being fair I must say my machine is running BTRFS, and is going
quite well, I don't
think I've felt much the performance hit.

--Best regards, Sergio
--Best regards, Sergio


2015-09-05 15:20 GMT+02:00 Liam Proven <[email protected]>:
> 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
_______________________________________________
gobolinux-users mailing list
[email protected]
http://lists.gobolinux.org/mailman/listinfo/gobolinux-users