Re: Fedora/RedHat is moving is a similar direction

2015-08-26 22:24 GMT+02:00 Trans <[email protected]>:
> On Wed, Aug 26, 2015 at 10:09 AM, Sergio Tortosa Benedito
> <[email protected]> wrote:
>> Now, if you want to discuss bundles vs packages, then, you should
>> start another thread.
>
> Okay. I am not 100% sure of the differences, so I might do that.
>
>> 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.

While that may be true , I think is really important and if it is the
only way then I'm fine with it, however, it might be interesting to
compare this design against another system designed from the ground
with this idea (the only one I know which does this is OS X).

> Wouldn't it be a whole lot easier just to give each user their own
> docker instance and isolate things that way? 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.)

I don't think that would end up well, docker is fine for what is
intended but if we did like this we would have an overcomplicated
system which indeed might lack flexibility. First, sanbox is there for
isolating every app (not just one or two) that way you don't have to
trust apps, even if you really trust them, maybe they have bugs which
may help hackers (examples could flash player or adobe reader, just to
name a few...), if we made an user for every app then we would end up
we would end up with a mess, and I don't know how we could limit users
accesing to applications.


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

Yes, it was exactly that, if we depend on snapshots we might need them
forerver ( or at least this may make the transition to another fs
somewhat difficult), and they are worth the pain? I don't think so.

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

Not really for a particular app, is just like a snapshot of /usr with
a set of libraries, so for example: you are making an app and you
target KDE 5.6 runtime, also your app just needs libfoo, if libfoo is
included inside the runtime, you are good to go, you can just package
your application (inside a bundle), otherwise libfoo must be include
in the bundle because the computers won't have that library available.

>>> 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.
True, I thought about it just after sending the e-mail, I wish this
was more or less automed though.

> 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.
Then the admin should just change the cache dir variable globally, I
think they did well with this.

> _____________________________________________
> gobolinux-users mailing list
> [email protected]
> http://lists.gobolinux.org/mailman/listinfo/gobolinux-users



-- 
--Best regards, Sergio