(Warning: long post, no worries: not a rant!)
Hi, Brokenman and Porteus community!
Happy new year and best wishes to everyone!
It's been a long time since my last post on the forum in mid-2014.
Back then, I have shared a UI/Productivity pack based on LXDE/compiz/cairo-dock, that I (and several friends) used as a portable setup.
Unfortunately, my time became very limited and I could not afford the hassle to maintain it.
And grew apart from the community...
However, I have to admit that Porteus community is a really good one, with (mostly) positive attitude, friendliness and warmth.
That's why I would like to provide my input as a programmer / admin / UI expert / user.
(BTW I still keep my Porteus 3rc1 setup on my usb drive.)
Preface:
Let me kindly remind us that software development/distribution is largely an organic/social process. This often becomes the limiting factor to the technical side. There is always the part of human nature that will resist change. People have deep attachments to their habbits and have difficulty being out of their comfort zone. Until they adapt that is, afterwards they feel at home - we all have been microsoft Windows users at some point.
SystemD:
From a regular user's standpoint it is not an issue at all. They don't know/care what is that thing called "init system". More advanced users may go as far as "systemctl start/stop/enable/disable unitName" to fine-tune their systems.
Personally, I'm fine with whichever init system the distro uses, as long as it is stable, works as expected and is well documented. Technically, systemd solves some non-trivial problems, among them enforcing unit dependency constraints and starting units in parallel. Binary logs may be annoying, but not show-stopping. (AFAIK one of the reasons is security: if a system is compromized, logs can be deleted by the intruder, but cannot be edited to make it look as if intrusion didn't happen.)
What I don't like is that some packages like Gnome require systemd. It's not systemd's fault that other devs made systemd package a prequisite. But there are workaround shims for such cases.
From dev's point of view, systemd's unit files add some work, but they also ensure correct behavior and order of initialization. Basically you describe your unit's behavior and systemd enforces the correctness and timing relative to other modules. I don't know if Porteus would need many custom units, but my hunch is that once those are properly set up they rarely need to be revisited.
Other than that, it is stable, well documented, well maintained and used in production. There are lots of interested parties invested in development of systemd, so quality, stability and longevity is basically guaranteed. I could not care less who commits code to it, as long as it is high quality - this is open source. There are conspiracy theories that systemd is a plot by Microsoft/RedHat/Devil to destroy linux / dominate the world - no comment here. I have no problem if big corps pay some bills, so we have less bugs.
About other init systems:
Ubuntu's upstart had its quirks too, but was bearable with relatively ok support.
SysV is theoretically the simplest but sometimes can become a mess with lots of scripts, when troubleshooting, but we still somehow managed.
OpenRC - don't know, never used, but heard good thing about it.
I have my reservations about using OpenRC on Arch because it is
not the default. I have nothing against OpenRC, but since it's not officially supported, there will have to be manual workarounds added in case there is an issue with a package. Also, possibly some unexpected issues because less ppl in upstream have it running/tested. That means more maintenance work for Porteus. I generally would suggest using only the base's *official* init system and leverage mainstream's work/testing/support.
It will be Brokenman's decision whether added work of supporting an unofficial init system outweights the added work of unit files. And I would wholeheartedly support that decision - who better than him knows the requirements and needs of Porteus' base.
Arch:
I use Arch as my daily driver for quite a few years now.
*
Documentation (wiki): it is very high quality. This can be vital help for those who wish to become contributors to Porteus, but don't have enough knowledge yet. Also always a good reference for main devs - noone can know it all. Ideally, any difference from Arch should be documented, so that potential contributors know for which topics *not* to refer to Arch wiki (modules/package management/layered filesystem etc). I have never posted on Arch's forums (found all my answers on wiki and googling), but their reputation is of being not very newbie-friendly. Porteus forums' culture is much better.
*
Arch build system (ABS): like slackbuilds, but with dependency resolution? Yes, please! Having been through Slackware's manual dependency resolution - it is time-consuming and error-prone. We are not in the stone age anymore, these things need to be automated as much as possible. For an odd package, that would pull many unwanted stuff, custom PKGBUILD can be made easily.
*
Rolling release: personally I never had any issues, where rolling nature of Arch was at fault. As with all software it is the particular package's quality that ultimately defines *what* you get (bugs/fixes/features), the rolling nature defines *when* you get them. I'm comfortable with updating once in about 3-4 weeks, if there is a bug, I update more often till I get the fix.
That being said, for production systems I prefer Ubuntu LTS and the added psychological sense of stability (since it is deployed on many mission-critical systems).
For Porteus to follow rolling scheme may put additional strain on users that don't know how to roll back updates in case of a rare bug. The base needs to be somewhat stable. That means taking a snapshot of Arch repo at a point in time and building Porteus around that. If a bug is encountered by user, then upgrade/downgrade to version with a fix, and (possibly) rebuild dependent packages.
The tricky part is AUR. Ideally, it's build files have to be snapshotted for the same point in time as main repo, to be consistent. AFAIK, Manjaro's stable repo is about 2 weeks behind Arch, while AUR is latest(correct me if I'm wrong). That difference in timing may trigger premature AUR package rebuilds and (more importantly) the lack of rebuild when needed. This can happen when AUR's package release version (the one after the last dash, like pkgName-1.3.4-2) is bumped due to dependency upgrade (from main Arch), it will be rebuilt. But if dependency upgrade hasn't reached Manjaro stable, the rebuild will result in exactly the same package. When dependency upgrade finally reaches Manjaro stable, the rebuild will not happen, because it already did, although against the old system base. There will be a need to rebuild manually and reinstall the package(easy with yaourt, but still..). Fortunately for the users, ABI changes like that happen rarely.
Good strategy with Arch as base IMHO is snapshotting/freezing Arch's repo (binary packages) and AUR's buildfiles to ensure no ABI inconsistency will happen. Then provide security updates only for the base and leave AUR to users.
Not sure how feasible that would be though(hosting, etc). Having Manjaro as base is interesting idea, it is still rolling like Arch, but may give you more stable snapshotted base.
Another good option would be Ubuntu LTS, which is fairly popular choice for distro base, with some documentation existing, and common user issues can be googled from official ubuntu forums. Also, lots of third-party ppa's and most proprietary vendors release for Ubuntu. Of course, different packaging system. Desktop distros like Mint switched to LTS for a good reason: to leverage the upstream's stability (they used to be based on Ubuntu-current). The bigger the user base, more chances that bugs would be tested/reported/fixed.
Porteus:
For me, what makes Porteus unique is:
- Architecture: aufs layered filesystem with persistence layer - being able to just delete the savefile to get a completely fresh system is unmatched! The whole concept of modules is excellent. Loading modules into ram makes Porteus faster than SSD install (depending on the cpu, but decompression times for xzm's are blazing-fast).
- Portability.
- Great community.
Some ideas for distant future:
- Tools to ensure no package gets duplicated in modules.
- Tools for breaking down(un-merging) modules consisting of >1 packages to single-package modules.
I truly love Porteus (it is my favorite distro ever, but I can't use it on daily basis due to needing many different and recent packages and Slackware made it painful). If I could contribute to one distro that would be Porteus. Unfortunately, I have no time at all currently, but who knows maybe in the future I will. I still read the forums from time to time, (now with this news will read more often)
and certainly will check out Porteus 4.0 when it's out.
Brokenman:
First of all you are awesome!
When I read the original post of the thread, I was amazed how accurate and spot-on your remarks were. You deservedly will be the driving force of Porteus' evolution. You are very talanted and the community trusts you. There will always be various disagreements, but that's how it is. Please continue to be pragmatic and logical in your technical decisions, as your always were. Remember that various systems are just tools for the job and keep your vision clear.
Lastly, when choosing distro for base, leverage it's strengths as much as possible and offload as much work to them as possible -
also in the long run. That will give you enough time to deal only with Porteus-specific stuff.
Apologies for such a big post, but I could not resist.