Seva wrote:1. make dl.porteus.org the official porteus repository and allow xzm module creators to publish their modules there
I don't know if there was a reply on that part in here, I currently have not the time to read all posts in this thread,
Anyhow, that was addressed already (not by me, I write this post just by what I recall from memory, too lazy and too tired trying to find the posts about the matter from others; could have been fanthom and brokenman who made the other replies to similar suggestions)
TL;DR:
Wanting users to be able to upload user-made modules needs complex and thought-out mandatory rules.
While these rules make sure that the modules crated have a high quality
it also makes it hard for new users, or users new to creating modules to make his/her first module that follows these rules.
___________________________________
Seva, I try to show you that, when wanting a standardized and high module quality (as we as community want that very much), even when there are several approached to meet that goal, every approach has its downsize, and severe downsized at times.
I hope I managed to explain the matter good enough to you so that you understand why this is a complex and complicated matter with no easy solution. [When you can think of a 3rd way, aside from the ones I mention below that would secure a high module quality and still makes it easy for users to crate these modules, without having a workload put on the main crew of Porteus, please tell us.]
You already know that our OS is a fork from Slax. In the older days of slack, everyone could create and publish modules on the main Slax module "repository"
Partly that sounds great, since it makes it easy for users to get their modules "published", but it has a downsize: there is no control about the quality and stability of all these modules, the user who created them is the only one who reviewed his own module, and the minds of most of us tend to overlook issues or possible issues in our own work we just finished...
Another approach to solve such issues is creating complex and strict rules of how-to-create modules like Tiny Core Linux does, The plus size: The modules all share a high quality standard by default. The flipside: For new users to the Live OS, or for long time users but first time module creators it can be very bothersome to crate modules that follow all the needed rules.
Like, I wanted to set up TinyCore x86-64 with some of my wanted and needed programs just to see how it can be used on a daily basis and with the same goal of productivity than Porteus XFCe, as in: palemoon, viewnior, geany, mtpaint.
Now, dunno about geany, but last I checked (some weeks ago) there is no TinyCore module for palemoon or viewnior, dunno about mtpaint.
And even for someone like me who created dozens
(maybe even approx a hundred? Honestly, I dunno, but when I also count the settings and firefox/palemoon and flash update modules I create on a regular basis for myself, at least 100 is sure a realistic number) of Slax, Slax remix and Porteus modules I was not able to create even one single module, since I not wanted to just make it for myself put share it with the TC community. But the rules needed to follow creating TC modules kinda .... killed that. AT the time I was stressed with the workload in RL (I am still under heavy load from RL, that is, and for the time being there is not a chance in sight... for now.)
I hope you can see that, by the need of having the modules on the official Porteus dl repo of certified and high quality there are not many rules to follow.
And another downsize to the way TincCore does that. Even when a poll in our community would agree to use the same approach as TC, it would not work to just copy verbatim the rules that TC uses for its own modules. Sure, they are compatible, you can activate TC modules in Porteus, since both use the same underlying technique and compression, the OS itself still differs a lot. TC is much more minimal than Porteus, which is the reason it is so small and so fast, but also a reason why some users who want their known KDE, or Mate, or XFCe have issues with TC...