Further Collaboration With Other Distros

[WickedFlick]

Hey all, hope you're all having a pleasant winter.

I'm a big supporter of collaboration in the open-source world, as more often than not it results in something better than the sum of its parts; MX-Linux being a shining example of that in action, with the Mepis and antiX communities coming together to deliver a cracking good distro!

With this in mind, I was wondering if anyone on the MX team has voiced the idea of continuing in that mold, and attempt to reach out to other distros that seem like good candidates for collaboration with MX-Linux?

For example, I've noticed some users here are fond of the idea of reviving the KDE version of MX, but this has been (rightfully, IMHO) put on the backburner so as to concentrate efforts on delivering a well-tested and properly stable OS. However, I've since encountered Neptune Linux, which clearly has skilled folk behind it and appears to have the same values as MX-Linux in design (Debian stable base with certain components kept more up-to-date, some custom tools, etc), but instead solely focuses on KDE as their main desktop environment.

At least to my mind, they seem like the perfect candidate to collaborate with on a KDE version of MX-Linux. Combining Neptune's KDE expertise with MX's superb base would (I assume) surely result in something fantastic. It could also neatly merge into the existing naming scheme (NMX-Linux, perhaps?).


But that's all my two cents, take it with a grain of salt.

Also, if you guys have any other suggestions as to other distros that would be good matches for collaboration with MX, I'd love to hear 'em!

[MAYBL8]

On the KDE subject and XFCE there is a Distro out there that is Called Solydxk.
Maybe you could reach out to them. I don't think they have a large user base.
I know their developer and founder could use a break and some help. Just my opinion.
http://www.solydxk.com

[Adrian]

Collaborating with somebody, while it sounds nice and fuzzy, is the same thing in terms of effort, or actually more, than doing something something by yourself. Think about it, if I'm to help a team member to work on a KDE version wouldn't that be easier that to help another team do it? How collaboration work in open source is mostly like this "hey, I tried your tool, it works nice but I would like it to do that, can you help?" or even better "hey, I added this feature/bug fix to your tool do a git pull if you are interested".

[Stevo]

I've tried to float the idea that Bunsen Labs could do a lot worse than merge with MX or antiX and provide their unique desktop on our base, and have access to our backports, but it floated like a lead balloon over there. Apparently I was generating a heavier-than-air gas...

We have had users add the NeptuneOS repos to get a newer KDE on MX with success, so adding each other's repos wouldn't be that difficult. They would have access to our backports and maybe some of the MX tools that aren't XFCE dependent, and we'd have a newer KDE.

[asqwerth]

[oops. ninja-ed by Stevo!]

I think there is at least 1 member here who enabled the Nepture KDE repo to install their version of Plasma (which is newer than the one in Debian Stretch repos).

If you check with Stevo, he will probably tell you that there are some users of other Debian-based distros who enable MX's repos to enjoy the newer backported packages and programs not even found on standard Debian. He is an active member of the Debian User Forum and already offers the packages he backports/compiles using the opensuse build service.

http://forums.debian.net/viewtopic.php?f=16&t=130057

Check out his forum signature at the bottom of that post.

I also remember specific mention of this (using MX's repos) by Crunchbang/Bunsenlabs users on their forum. And I myself use a hotcorner script from Bunsenlab's git, which I have linked to in my MX wiki entry on enabling hotcorners in MX17/18.

At one stage, Dolphin_Oracle tried to experiment with making an Appimage of the MX Live USB Maker, so that it could be downloaded and run by users of other distros. Didn't really work very well, though.


Other than that it might be impractical to have true collaboration between 2 groups of team members that might be very different in their collaborative and development style, have different goals, etc. There might also be some small issues from the fact that most of Debian is on systemd while MX is still using sysvinit.

[aledie]

I also remember specific mention of this (using MX's repos) by Crunchbang/Bunsenlabs users on their forum.

Some BL guys there experimented with antiX repos:
https://forums.bunsenlabs.org/viewtopic.php?id=4264

I used to use BL hydrogen installed on the top of LM XFCE a year ago, when my old PC became slow. Was not bad, I was in fact a fan of BL.

So I played around with adding BL Helium Repos to antiX-base a week ago. The install wasn't completely smooth in my case, but I did just spend few hours on this. When however I did put Helium repos onto MX-18 a few days ago, it went just fine, pretty, runs very nicely, OB menus need some extra work on (or I will just put some openbox menu generator or replace Tint2 with XFCE/LXDE panel to spare the manual edits). Also i don't use bl-exit which needs systemd, but lxsession-logout. The rest works fine. BL Helium looks very polished and pretty compared to traditional grey CB.

I'm not sure yet, I want it to be BL looking/ acting MX or full BL setup on the top of antiX core/ reduced MX, probably the first.

[azrielle]

Having used Sparky repo a time or two with MX16 (primarily to access the Sparky Rescue Conky), and having used Sparky minimalGUI and Bunsenlabs Hydrogen, Deuterium (UGH), and Helium, and even though Sparky uses systemd, I'd still recommend Sparky minimalGUI (which is Openbox) over Bunsenlabs. Who knows, maybe Pavroo could be convinced to do somecollaboration?

[dreamer]

Debian can set up a PPA system so not the same application has to be packaged two, three or more times for Stretch based distros. Ideally the app is packaged by the app developer, but I know deb packaging isn't easy. Anyway it's unlikely to happen with AppImage, Flatpak and Snap taking the place of PPAs even in the Ubuntu world. PPAs are likely on their way out and they are a security risk if you don't trust the PPA maintainer which goes for all repos.

I do think the PPA system was what propelled Ubuntu, Linux Mint and other derivatives to such heights in the past. It was an ecosystem that was bigger than one distro. Maybe we see the same thing with Arch-based distros today, where AUR seems to be still going strong.

[Stevo]

Packagers can do essentially the same thing or more with the openSUSE Build Service as PPAs, since PPAs are restricted to Ubuntu releases. I'm only using a fraction of its possible distro builds for the Pale Moon builds, since there is still no PPA for that:

https://build.opensuse.org/package/show ... r/palemoon

[dreamer]

Packagers can do essentially the same thing or more with the openSUSE Build Service as PPAs, since PPAs are restricted to Ubuntu releases. I'm only using a fraction of its possible distro builds for the Pale Moon builds, since there is still no PPA for that:

https://build.opensuse.org/package/show ... r/palemoon

I guess the PPA system is dying, it's all about Snap now. Automatic updates in the background and focus on proprietary apps. They already found a coin miner in the Snap store. The irony is that the only reason they found it is because the malware creator was kind enough to make it open source.

PPA = Use your head/judgement - kind of like downloading an .exe for Windows. Not every site should be trusted.

(PPAs were the glue between Ubuntu users and .exe files are the glue between Windows users, but there is no glue holding Debian users together. Debian doesn't have desktop ambitions and that's perfectly fine.)

Snap = Trust us