The path to follow for porteus modules

Technical issues/questions of an intermediate or advanced nature.
port
Samurai
Samurai
Posts: 137
Joined: 18 Feb 2016, 09:25
Distribution: Linux porteus 3.2.2 KDE
Location: Spain

The path to follow for porteus modules

Post#1 by port » 07 Oct 2016, 10:16

I'm working in a project regarding porteus modules and their distribution and a question arise...

What design would be better for a module?
  • a module per application
    In this model each application is distributed as a module and that module contains all needed for application to work.
    Pros:
    - download, activate & run... just easy & fun!
    - it's posible to make up a system full of modules (no need for install anything not being itself a module) ** mainly in a happy world nowadays **
    - it's posible to install and deinstall software on demand (i.e when this event happens activate this module)
    - autocomplete, all needed is in the module, install is just a matter of copy&paste
    Cons:
    - you will have a lot of files duplicated in your storage (imagine a library file used for a lot of applications)
    - Files in modules may hide files in the system or other modules when activated
    - maybe library hell or library mesh!
  • a light module per application
    In this model each application is distributed as a module but that module contains only application files and maybe dependent resources not very common or specific to the app.
    Pros:
    - often just activate and run but... sometimes you have to work installing extra things
    - you use common resources in the system
    - better use of storage due to lowering duplication
    Cons:
    - this model requires the existence of 'common resources modules' or coexistence with alternative installing methods (i.e. usm)
    - Difficult to set what have to be inside and what outside the module (How common is a resource?)
  • a module per collection
    In this model each modules packs a collection of software for a common use, i.e. development, office, painting, electronics... It will include all files needing for all software in the module.
    It's the same concept of first model but with a compromise between pros and cons just packing related software in a rational way.
    Pros:
    - activate and run
    - profile oriented, you can build and distribute modules for specific profiles of users or niches (i.e programmers, musicians, artists, writers...)
    - modular (you can evolve and grow in a modular way, even porteus may be modularized as it is already but to a greater extent)
    - you use common resources in the system (they will be a module!)
    - better use of storage due to lowering duplication (a compromise)
    Cons:
    - requires planning to decide what to include in each module
    - module clashing (target users need software not available in a module and make a slighty different module or maybe different modules for different targets share common software)
  • any other model ?
Feel free to contribute to the discussion adding new models, pros and cons. I'm very interested in your opinions!

fullmoonremix

Re: The path to follow for porteus modules

Post#2 by fullmoonremix » 07 Oct 2016, 15:15

IMHO... an autonomous 001-core.xzm (which I'm currently building from scratch using depfinder) that
simply boots and builds might be a good model. It would eliminate dependency hell and "just work".

This would greatly reduce redundancy and make it easier to do homebrews w/ USM (CLI).

Regards.

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: The path to follow for porteus modules

Post#3 by brokenman » 07 Oct 2016, 22:39

a module per application
There is a script called 'bundles' in 3.2+ to handle this. There are no current bundles created for v3.2rc5

The model with a single application per module is complicated as it may only run on the desktop in which it was created. For example a module for a K application may only run in KDE but not in XFCE due to desktop specific libraries.

I'm not exactly sure what fullmoonremix means as the core modules are desktop agnostic.
How do i become super user?
Wear your underpants on the outside and put on a cape.

fullmoonremix

Re: The path to follow for porteus modules

Post#4 by fullmoonremix » 08 Oct 2016, 03:04

I was referring to doing a homebrew Porteus from "scratch" build.

To build on top of a complete Porteus (001-003 xzm's) the current USM (GUI) approach is a perfect solution.

However... a homebrew Porteus (001-core.xzm + custom build) requires
001-core.xzm to function w/out requiring 002-xorg.xzm.

Currently... because of NetworkManager's numerous 002-xorg.xzm dependencies
a 001-core.xzm scratch build is not possible using solely 001-core.xzm.

I have spent the last 2 months trying to correct this issue (in part by switching to ConnMan ) and I
now have a functional homebrew 001-core.xzm CLI prototype that does not require 002-xorg.xzm.

Basically... what I did was deprecate** 002-xorg.xzm by removing X11 and adding it to 001-core.xzm.
My goal is to use the 002 module only for drivers... a PekWM GUI and Mesa dependent packages.

**This was done while avoiding Gtk/Qt bloat like the plague.

port
Samurai
Samurai
Posts: 137
Joined: 18 Feb 2016, 09:25
Distribution: Linux porteus 3.2.2 KDE
Location: Spain

Re: The path to follow for porteus modules

Post#5 by port » 11 Oct 2016, 13:18

brokenman wrote:
a module per application
The model with a single application per module is complicated as it may only run on the desktop in which it was created. For example a module for a K application may only run in KDE but not in XFCE due to desktop specific libraries.
yes, that a big issue and the solution is to provide several modules for different desktop managers (kde-mymodule, xfce-mymodule...) or make modules desktop agnostic including all required for the application to run unless resources related to desktop managers (suposing you alredy has those resources as you've installed a desktop) which implies having desktop modules.

The question in terms of porteus base modules is if the model should be similar to 04-firefox.xzm or similar to 05-devel.xzm

Bogomips
Full of knowledge
Full of knowledge
Posts: 2564
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Re: The path to follow for porteus modules

Post#6 by Bogomips » 11 Oct 2016, 22:43

port wrote:
  • a module per application
    In this model each application is distributed as a module and that module contains all needed for application to work.
  • a light module per application
    In this model each application is distributed as a module but that module contains only application files and maybe dependent resources not very common or specific to the app.
  • a module per collection
    In this model each modules packs a collection of software for a common use, i.e. development, office, painting, electronics... It will include all files needing for all software in the module.
    It's the same concept of first model but with a compromise between pros and cons just packing related software in a rational way.
Formalised something that crops up in my deliberations from time to time.

Not looking at the big picture. What if I have are two or more applications, all needing QT, like QTerminal and VLC. Now QTerminal is almost all QT, so it would pay to always have QTerminal activated. Given that all the items on the menu are on loops anyway, then this is just one more item on the menu which I may or may not be used, but this then gives the advantage of smaller modules all around for QT dependent apps. like VLC.

Also, if not using copy2ram or loading over a network, it would be interesting to quantify the advantage of a smaller module, which I suppose would be a function of loop overhead and aufs overhead. :unknown:
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

User avatar
Ed_P
Contributor
Contributor
Posts: 8341
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Re: The path to follow for porteus modules

Post#7 by Ed_P » 11 Oct 2016, 23:32

If 2 modules share a subsystem like QT and both modules are loaded, doesn't the subsystem of the second one overlay the subsystem of the first one? If so there is no wasted RAM having the subsystem in each module. There maybe some duplicate storage space used but not RAM.
Ed

Bogomips
Full of knowledge
Full of knowledge
Posts: 2564
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Re: The path to follow for porteus modules

Post#8 by Bogomips » 12 Oct 2016, 00:34

Ed_P wrote:There maybe some duplicate storage space used but not RAM.
What if you use copy2ram?

Actually had in mind difference in cpu load, more critical for machines stretched performance wise. Have not investigated in depth the mechanics of how similar directories on one loop overlay those on another loop. :unknown:
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

Post Reply