Limba: Experimental Linux Software Installer Using OverlayFS

[phoronix]

Phoronix: Limba: Experimental Linux Software Installer Using OverlayFS

Running off systemd's new Linux software/packaging vision, Matthias Klumpp has proposed Limba, an experimental software installer that doesn't depend upon Btrfs but rather technologies that have been mostly mainline for a while...

http://www.phoronix.com/vr.php?view=MTgzNDg

[MrEcho]

Giving power back to the upstream

I there theres two main points to this system. One being that people want to get updates from the developers who make the software, like Firefox and Chrome. Second is that desktop applications management on Linux sucks.

There are many times when you have to wait for the distro to update their repo to the newest version, this could be awhile if its not a security update. Sure you could compile it yourself, but where talking about desktop users. Try telling a Windows or a Mac person that.

The second part is a bit more complex, and it extends from just how Linux is setup in general. An application could have bits and peaces all over the file system, and you MUST track where all these files are at for updates and such. This is why we need package managers. If you don't use the package manager, or a custom repo for your application, your going to shoot yourself in the foot at some point.

If you look how Windows and Mac do their desktop applications, its very easy for the desktop user. And on the Mac, its just a file(container), you can just move the application around, anywhere on the file system. There is a standard place where the application can store stuff, on Windows and Mac. How many ~/.dir's do you have on a very busy Linux desktop?

"I" think the biggest issue for the Linux desktop is the lack of a single unified SDK, something that only updates once a year. The LSB is a joke.

https://developer.apple.com/library/mac/navigation/

http://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx

http://refspecs.linuxfoundation.org/lsb.shtml (Note the dates)

[blackout23]

A universal application container should be:

a) a single file
b) not require root to install
c) not require package maintainers
d) run everywhere
e) provide bit for bit the same environment that the app was developed and tested in
f) not influence any other installed apps or the system in anyway
g) be able to install multiple versions
h) be provided directly by the developer
i) sit in the repo of the developer, which is linked into a greater Linux software repo to make everything globally serachable without requiring a giant FTP server.

[gens]

...

this is not about application containers
it's about different programs requiring different versions of libraries

a problem that has been solved in many ways thus making it not a problem at all
this, Limba, has also been done, al be it slightly different (it's better then the dumb idea from that other guy)


http://en.wikipedia.org/wiki/Plan_9_...and_namespaces is what it comes down to

bdw, if you are hot for containers
http://lwn.net/Articles/531114/ and the link above

[Calinou]

How many ~/.dir's do you have on a very busy Linux desktop?

http://standards.freedesktop.org/bas...ec-latest.html is a specification for standard paths, quite well-made in my opinion, as long as you follow it properly. Sadly, lots of developers refuse to follow it. Blame them.

Also, no, unified SDKs often are a joke. They can end up having lots of limitations or being managed by lobbies (W3C).

[gens]

I there theres two main points to this system. One being that people want to get updates from the developers who make the software, like Firefox and Chrome. Second is that desktop applications management on Linux sucks.

There are many times when you have to wait for the distro to update their repo to the newest version, this could be awhile if its not a security update. Sure you could compile it yourself, but where talking about desktop users. Try telling a Windows or a Mac person that.

The second part is a bit more complex, and it extends from just how Linux is setup in general. An application could have bits and peaces all over the file system, and you MUST track where all these files are at for updates and such. This is why we need package managers. If you don't use the package manager, or a custom repo for your application, your going to shoot yourself in the foot at some point.

If you look how Windows and Mac do their desktop applications, its very easy for the desktop user. And on the Mac, its just a file(container), you can just move the application around, anywhere on the file system. There is a standard place where the application can store stuff, on Windows and Mac. How many ~/.dir's do you have on a very busy Linux desktop?

you can just dl the latest firefox, untar it somewhere (there are predetermined places for it) and just run it from there (or make a .desktop file, that would work for any DE)
just like better DOS

and no, windows and osx ways are by far not bulletproof
everybody had weird trouble with windows programs misbehaving after installing some other, unrelated, windows program

[gens]

http://standards.freedesktop.org/bas...ec-latest.html is a specification for standard paths, quite well-made in my opinion, as long as you follow it properly. Sadly, lots of developers refuse to follow it. Blame them.

Also, no, unified SDKs often are a joke. They always end up having lots of limitations or being managed by lobbies (W3C).

freedesktop is slowly going to ***
just following the LSB FHS and making a .desktop file is good enough, and there are OSS installers that follow that

[pal666]

How many ~/.dir's do you have on a very busy Linux desktop?

two: .config and .local

[pal666]

on topic: btrfs is too new, so lets depend on 3.18-only thing

[steveriley]

two: .config and .local

Thta's all you have? Way more here:

steve@t520:~$ [B]ls -Al | grep '^d' | grep '\.'[/B]
drwx------ 1 steve steve      24 May 19 00:20 .adobe
drwxr-x--- 1 steve steve      32 Jun  8 00:08 .android
drwx------ 1 steve steve      22 Nov 10 13:50 .aptitude
drwx------ 1 steve steve     410 Oct 25 01:19 .cache
drwx------ 1 steve steve     430 Nov 10 13:09 .config
drwx------ 1 steve steve      18 Jul 20 12:58 .cups
drwx------ 1 steve steve      22 May 10  2014 .dbus
drwx------ 1 steve steve     174 Nov 10 10:49 .dropbox
drwxr-xr-x 1 steve steve      82 Sep 12 18:33 .dropbox-dist
drwx------ 1 steve steve       0 Oct 16 15:56 .freerdp
drwx------ 1 steve steve       0 Nov 10 11:25 .gconf
drwx------ 1 steve steve     168 Nov 10 16:37 .gnupg
drwx------ 1 steve steve       0 Jun  7 20:32 .gphoto
drwxrwxr-x 1 steve steve       0 Oct 25 02:32 .groove
drwxrwxr-x 1 steve steve      38 Aug 18 16:52 .gstreamer-0.10
drwxrwxr-x 1 steve steve      10 May 17 09:40 .java
drwxrwxr-x 1 steve steve      82 May 19 23:10 .kchmviewer
drwx------ 1 steve steve     108 May 10  2014 .kde
drwxr-xr-x 1 steve steve      10 May 10  2014 .local
drwx------ 1 steve steve      24 May 19 00:19 .macromedia
drwx------ 1 steve steve      34 May 19 00:06 .mozilla
drwxrwxr-x 1 steve steve      12 May 17 10:34 .mplayer
drwx------ 1 steve steve      14 May 10  2014 .nv
drwx------ 1 steve steve      10 May 10  2014 .pki
drwx------ 1 steve steve     662 Nov 10 10:49 .pulse
drwxr-xr-x 1 root  root      304 Oct 30 09:27 .rpmdb
drwx------ 1 steve steve      22 May 11  2014 .ssh
drwx------ 1 steve steve      22 May 10  2014 .thumbnails
drwxrw---- 1 steve root       62 Aug 18 16:52 .ViberPC
drwxrwxr-x 1 steve steve      44 Aug  7 10:10 .webex
drwx------ 1 steve steve     254 Jun 14 00:32 .yate