The future of Porteus

New features which should be implemented in Porteus; suggestions are welcome. All questions or problems with testing releases (alpha, beta, or rc) should go in their relevant thread here, rather than the Bug Reports section.
User avatar
tmsg
Black ninja
Black ninja
Posts: 44
Joined: 15 Sep 2015, 14:29
Distribution: arch, mx, porteus
Location: York, UK

Re: The future of Porteus

Post#166 by tmsg » 11 Dec 2015, 13:05

Apart from some of the language, I agree with most of what JosepZ wrote.

The Brits have a saying... "He who pays the piper calls the tune". AFAICS the dev(s) are not simply paying the piper, they *are* the piper! They build this w/o payment, in their own free time and we should be glad and thankful that they are actually willing to argue their case and to listen. I for one would have absolutely no problem with a BDFL approach... if I don't like what I see I can always take one of the myriad other Linux distros.

Just to reiterate what I'd list as my main priorities:
1. Modular and not a rolling distro.
2. Small, fast, bare bones.
3. A fully-featured development module.
4. A reliable package manager.

User avatar
francois
Contributor
Contributor
Posts: 6434
Joined: 28 Dec 2010, 14:25
Distribution: xfce plank porteus nemesis
Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.

Re: The future of Porteus

Post#167 by francois » 12 Dec 2015, 14:41

According to what is going on with nemesis development (rc). this is exactly what you should get. In order words Porteus slackware with more packages availability and some way to the rolling release less rolling.

Try it here in How to get it:
http://forum.porteus.org/viewtopic.php?f=137&t=5066
Prendre son temps, profiter de celui qui passe.

User avatar
tmsg
Black ninja
Black ninja
Posts: 44
Joined: 15 Sep 2015, 14:29
Distribution: arch, mx, porteus
Location: York, UK

Re: The future of Porteus

Post#168 by tmsg » 12 Dec 2015, 18:19

francois wrote:Try it here in How to get it:
http://forum.porteus.org/viewtopic.php?f=137&t=5066
Guess what?! I've already done that...! Thanks to VirtualBox playing around with these things is easy and painless.

It's still early days of course, but Nemesis looks very good. For my current project I'm more interested in a stable environment, so I'll stick with 3.1 but once there's a stable XFCE version I'll take a very close look:-)

User avatar
JosepZ
White ninja
White ninja
Posts: 16
Joined: 21 Jul 2014, 19:39
Distribution: Porteus 3.0
Location: Barcelona

Re: The future of Porteus

Post#169 by JosepZ » 15 Dec 2015, 12:52

tmsg wrote:Apart from some of the language, I agree with most of what JosepZ wrote.
Yeah, sorry about that. We Mediterraneans tend to be foul-mouthed. Especially when we're pissed! :D

mparillo
Black ninja
Black ninja
Posts: 32
Joined: 14 Mar 2014, 19:11
Distribution: Porteus-KDE-v4.0-x86_64.iso
Location: USA

Re: The future of Porteus

Post#170 by mparillo » 27 Dec 2015, 00:36

I stumbled on this thread also. What I really liked was the using a simple web page, my ISO had just what I wanted it (Plasma 4, Chrome). Will that function to build your own ISO still be offered in the Future?

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

Re: The future of Porteus

Post#171 by brokenman » 27 Dec 2015, 15:30

That would be up to Hamza. If not I could certainly create a minimal Porteus install where you run a wizard client side to build your own distro.
How do i become super user?
Wear your underpants on the outside and put on a cape.

fullmoonremix

Re: The future of Porteus

Post#172 by fullmoonremix » 01 Jan 2016, 18:29

Salutations... :good:

IMHO... :oops: I believe Slackware Porteus should NOT be thrown under the bus
(@ least not until maintainers reach out to the community to maintenance fork it).

IMHO... :oops: I believe to solve the developer (and binary?) shortage for Porteus
it should be "ported" to the 4 major userlands (eg. deb... rpm... txz... tgz...).

IMHO... :oops: I believe Adeos (nanokernel) should be inserted under the kernel.
This would make Porteus the most (even more secure) ... self-healing (fault tolerent) OS.

IMHO... :oops: I believe Porteus should be "ported" to ARM (nVidia/Parallella).
nVidia is not friends with Intel anymore. And already Arch and ?Buntu are in bed with nVidia and Parallella.
https://www.parallella.org/
http://www.nvidia.com/object/jetson-tx1-dev-kit.html

There are many like me that are NOT comfortable with systemd. :wall:
If Porteus is "ported" it gets ALL of the major distro systemd refugees.

Hmmm... :evil: "One ring to rule them all and in the darkness bind them..."

Best Regards... :beer:

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

Re: The future of Porteus

Post#173 by brokenman » 01 Jan 2016, 20:22

Code: Select all

I believe Slackware Porteus should NOT be thrown under the bus
It won't be thrown under the bus.
I believe to solve the developer (and binary?) shortage for Porteus it should be "ported" to the 4 major userlands
Slight problem, developer shortage to port it.
I believe Adeos (nanokernel) should be inserted under the kernel.
Then it wouldn't really be so slackware based. Plus I am not familiar with nanokernel and don't have enough time to get acquainted with it.
I believe Porteus should be "ported" to ARM
That would be great. Again, see above reasons for not doing this. I think Ahau made some headway in this direction. He can attest to the (ever changing) work involved in pursuing this.
There are many like me that are NOT comfortable with systemd.
Perhaps you haven't been keeping up with the non-slackware version of Porteus. It doesn't use systemd.
If Porteus is "ported" it gets ALL of the major distro systemd refugees.
If the issue really IS using systemd, then let them come running. We won't be using it.

After much testing, I've decided the best route (if we change base) will be to a Manjaro core with openrc as an init system. Systemd has been removed from the system in favour of eudev and libgudev.
How do i become super user?
Wear your underpants on the outside and put on a cape.

fullmoonremix

Re: The future of Porteus

Post#174 by fullmoonremix » 03 Jan 2016, 15:25

Salutations... :good:
It won't be thrown under the bus.
Good news... :good: couldn't really tell if the decision was made to maintenance fork yet.
Slight problem, developer shortage to port it.
IMHO... :oops: Already 50% of that shortage (community?) has been resolved with .txz (Arch) and .tgz (Slackware).
If .deb (Debian) and .rpm (Redhat) joins the party "one ring will rule them all".
Then it wouldn't really be so slackware based.
IMHO... :oops: Nemesis is not really Slackware or even Arch based.
What Nemesis (which rejects systemd although Arch embraces it) is actually...
thinking outside the box which makes it much... much... more.
Adeos (if explored) might just make it even more security based.
. Plus I am not familiar with nanokernel and don't have enough time to get acquainted with it
IMHO... :oops: my point of view as usual is based on what to consider NOT what to do.
That would be great. Again, see above reasons for not doing this.
IMHO... :oops: see the above response.
Perhaps you haven't been keeping up with the non-slackware version of Porteus. It doesn't use systemd.
I keep up with everything Porteus. It has been my home for the past 13 months and I see no end in sight.
I was referring to ".deb" and ".rpm" NOT "txz".
If the issue really IS using systemd, then let them come running. We won't be using it.
IMHO... :oops: we will not likely hear from them until there are ".deb" and ".rpm" versions.
This is because many will remain in spite of opposition to systemd or they will reject Linux for BSD.

Better they migrate to Porteus than BSD. :good: In truth... I have spent the last 13 months working on a derivative
(as I have absolutely no interest in forking) that incorporates much of what I think might be useful.

Unfortunately... currently it is "alpha" (highly unstable). :wall:

Best Regards... :beer:
Last edited by fullmoonremix on 03 Jan 2016, 16:54, edited 1 time in total.

User avatar
dimx
Contributor
Contributor
Posts: 42
Joined: 02 Dec 2013, 08:10
Distribution: porteus-LXDE,Slackware,Arch
Location: Greece

Re: The future of Porteus

Post#175 by dimx » 03 Jan 2016, 16:37

(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! :Bravo: 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. :oops:

User avatar
Tonio
Contributor
Contributor
Posts: 276
Joined: 28 Dec 2010, 16:37
Distribution: Slackware,porteus,FreeBSD,Slax
Location: 127.0.0.1

Re: The future of Porteus

Post#176 by Tonio » 05 Jan 2016, 03:14

@dimx
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.
Stable? well documented? maintained and used in production? I have to highly disagree here. I also use other technologies mainly fedora where they brought this stuff many moons ago, but the red hat main distro[Enterprise Linux] did not use it yet. Now when they are changing base, many users[enterprise payers] are not happy with this stuff[old working scripts, no longer work]. They do not have ease, and no matter how much they(developers) others say that things are simple, they will never be as simple and easier and better documented than BSD Style init scripts that Slackware, Crux and other old school folks use. For *Regular Users*, yes you would be right they would not care what is under the hood, they would just care for a working desktop working internet and working apps. You do make some very good points. systemd is a plot by Microsoft/RedHat/Devil to destroy linux / dominate the world - no comment here It could be? We do not know for sure, but there is also selinux and other technologies that NSA could incorporate somehow and they could get whatever we write/do/script/etc. Age of Big Brother and Orwell's 1984 are coming of Age.
SysV is theoretically the simplest but sometimes can become a mess with lots of scripts, when troubleshooting, but we still somehow managed This is not true, they had a utility called chkconfig which listed the service(s) which were running and which ones were not, they had rc.d/ folders rc.1/ rc.2/ rc.3/ rc.4/ rc.5/ rc.6/ rc3 text login, rc5.login was X started and they corresponded to some number S99*** S90 which started before the S99 and so on that some services started before others as they were needed. I know about this because I had to use this stuff. Nowadays, there are shit loads of services running and we do not know what the fsck* they are doing :( I can see if I run any modern/new version of linux and compare it to any BSD, there are much more services running that who knows what is going on in our machines? and that systemd stuff just adds complexities to startup. Also that guy(developer) who brought systemd brought PulseAudio which solved a problem that did not exist with alsa and/or with oss. Sure it does nice things and could take sound system out of the stone age, but if it aint broken, why fix it? Keep the KISS philosophy in place. I guess users would be against using Ubuntu as a base, because a thousand or so other distributions already use it, Debian is also the mother distro of Ubuntu so that too would be out of the question. Maybe rpm based one? OpenSuse(but they are sleeping with the devil ? :wink: use zypper to solve deps) Fedora(but they are the ones that brought this mess(systemd and tested it and use it, and also work with NSA and also the devil :roll: :), but they dnf(yum replacement) which solves deps as well. The init system should not matter, but unfortunately some old timers/system admins/ would never give thumbs up to systemd, they would not agree with its inclusion. Ultimately Brokenman is the one that has the decision in his hands. I really like his answer in what he has posted. We may not agree 100% of the time, but I see his points and his reasons. His post summarizes many good things and since I am a guinea pig, I just want to test and try to help out when I have a chance. I will have much work to do, so I may not be here much, but I do pay attention and try to follow what is happening.

User avatar
dimx
Contributor
Contributor
Posts: 42
Joined: 02 Dec 2013, 08:10
Distribution: porteus-LXDE,Slackware,Arch
Location: Greece

Re: The future of Porteus

Post#177 by dimx » 05 Jan 2016, 12:22

@Tonio
I understand your dislike towards systemd, (I myself often oppose change). Here what Linus Torvalds says about it:
Question: There wasn't a decent unix-like kernel, you wrote one which ultimately became the most used. There wasn't a decent version control software, you wrote one which ultimately became the most love. Do you think we already have a decent init system, or do you have plan to write one that will ultimately settle the world on that hot topic?

Linus: You can say the word "systemd", It's not a four-letter word. Seven letters. Count them.

I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.

Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision.

Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys.
And he uses systemd on his main system.
Stable? well documented? maintained and used in production?
Yes, it is already and the trend is only going to increase (RHEL/CentOS 7, Debian, Ubuntu etc). Most newly deployed systems also use systemd. Old production systems with sysV scripts accumulated over the years can be tricky to port to systemd, but it can be much more painful to stay with them. Have you seen a production system with init mess that no admin dares to touch with a long pole? Not a pretty sight...

My main point was not systemd itself, but the use of non-default non-supported init system.
Ultimately, init + OS base choice is irrelevant in the big picture.
What is important is leveraging as much work from upstream as possible.
That which would provide less maintenance burden from Porteus - and if possible, in the long run too.

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: The future of Porteus

Post#178 by fanthom » 05 Jan 2016, 12:58

What is important is leveraging as much work from upstream as possible.
Agree in 100%.

For the last couple of weeks i was fighting with Mesa upgrade in Kiosk. System locked up completely on Intel GPU when starting Xorg. No debugging possible, no help from google.
After countless number of tries i have found that i need to abandon i486 arch and move to i586 as 'march=i486 mtune=i686' gcc flags no longer produces correct code for the Intel driver. 'march=i586 mtune=i686' is the way to go now.

Surprise surprise: Slackware introduced first i586 packages for Mesa and librdm in May 2015:
ftp://ftp.osuosl.org/pub/slackware/slac ... ngeLog.txt

Code: Select all

x/libdrm-2.4.60-i586-1.txz:  Upgraded.
x/mesa-10.5.4-i586-1.txz:  Upgraded.
They must be hit by this bug already and I could avoid the pain of debugging this problem myself if kiosk was strictly based on upstream distro (gentoo leaves the freedom of picking random gcc and USE flags == not everything is tested super well).

@brokenman
I would consider switching Desktop edition to Ubuntu LST as dimx pointed in his previous post. I cant do the same for kiosk as its very specific distro where Ubuntu would not fit well (bloat wise).
Please add [Solved] to your thread title if the solution was found.

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

Re: The future of Porteus

Post#179 by brokenman » 05 Jan 2016, 22:55

We do not know for sure, but there is also selinux and other technologies that NSA could incorporate somehow and they could get whatever we write/do/script/etc.
Wouldn't it much more effective (and sneakier) to hijack some other core package that all linux like systems use? I mean, everybody is saying systemd could be where the nasty stuff is hidden so why would someone hide something where everyone is looking? It just doesn't make sense. In any case, they are beyond this now. Why not go even higher, to the hardware manufacturers. Doesn't matter what OS you run if the hardware is bugged.

Anyway, enough of the systemd bashing. It's there, it works, we aren't using it.

So what would the advantages be of an Ubuntu based Porteus over arch? I've never used ubuntu. When I look at the livecd operating systems there are many for Ubuntu, but not so many for arch.
How do i become super user?
Wear your underpants on the outside and put on a cape.

aus9

Re: The future of Porteus

Post#180 by aus9 » 06 Jan 2016, 06:57

When I look at the livecd operating systems there are many for Ubuntu, but not so many for arch.
yep List of live CDs: Ubuntu-based

and scroll up to see the arch list.

Locked