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.
fullmoonremix

Re: The future of Porteus

Post#196 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: 5439
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: The future of Porteus

Post#197 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#198 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#199 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:

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

Re: The future of Porteus

Post#200 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#201 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
Site Admin
Site Admin
Posts: 4547
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: The future of Porteus

Post#202 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: 5439
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: The future of Porteus

Post#203 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#204 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.

aus9

Re: The future of Porteus

Post#205 by aus9 » 06 Jan 2016, 07:17

So what would the advantages be of an Ubuntu based Porteus over arch?
Actually I think the question should be more vague and say based over any other distro?

And here the plot thickens.

generally we agree that the reasons to change away from Slackware are threefold or more?
1) lack of ready made packages off the shelf so a newbie says I want X and can get it
------so distros based not on Slackware feature strongly here such as Debian Ubuntu etc

2) Difficulty in maintaining the base
Has many causes of which at least one relates to what is commonly called dependency issues.

Below is just a hypothetical example can be true quite often
--if upstream maintainer for (say) glibc updates and downstream distro maintainer updates but other downstream maintainers don't update there can be breakage for some software

Debian has a stable, testing and unstable branch. "Most" experienced Debian users tend to opt for either a mix of stable and testing or go whole hog and go unstable.
unstable is of course a rolling release.

*Ubuntu is mainly a type of Debian stable distro.

3) An off-shoot of this chat is those wanting less frequent updates would want a base that is NOT rolling. But then suffer some pain just as some Debian software might take 2 years to get from unstable to stable.

I fall into the camp of wanting frequent updates and so don't really care how out-of-date the iso is, as long as on my hd install I can update it.

*Ubuntu offers Long Term Support releases versus short term with the obvious comment that LTS generally has less frequent updates and are mainly security related rather than feature related. Rolling releases are generally moving targets so tend to have few security updates and nearly all are feature updates (software upsteam updates)

4) Flogging a dead horse? some people appear to believe if a distro has a certain init style they won't use it.

I am not sure if that is any clearer but let me digress into our modules talk.

Lets say a person one year ago downloaded and accepted combined modules to allow them to get software X.
Lets pretend today they want new software Y and accept combined modules.
--lets pretend that X has old dependencies and Y has new dependencies for sofware called Z.

This can lead to a new dependency issue. In some ways me thinks it might be better not to combine any modules. But I firmly believe we will have more issues of this type if we choose a distro with a rolling release base.

cheers

fullmoonremix

Re: The future of Porteus

Post#206 by fullmoonremix » 06 Jan 2016, 11:48

Salutations... :good:
So what would the advantages be of an Ubuntu based Porteus over arch?
There are none because the user makes that determination.
Which is why... :evil: "one ring should rule them all".

If every user base is covered (including ARM which is the future @ least for supercomputing)
then Porteus becomes the default. (Of course... that is provided systemd is thrown under the bus).

Best Regards... :beer:

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#207 by dimx » 06 Jan 2016, 14:59

brokenman wrote: So what would the advantages be of an Ubuntu based Porteus over arch? I've never used ubuntu.
- Installed on millions of desktop pc's. Arguably has the largest user base (more so if also counting derivatives like Mint). Achieves high quality of desktop packages, due to lots of feedback/bug reports from users. It is good to leverage this amount of maintenance.
- LTS version is very stable and has backports repo, in case user opts for more recent/potentially buggy packages.
- PPA's: Personal package archives: there are lots of them, and many are very high quality for getting unsupported packages. Users never need to compile/recompile packages themselves.
- Proprietary vendors support (as opposed to Debian)
- Good googlability for solving common issues from official forums.
What about disadvantages?
- The upcoming LTS (16.04) will be using systemd, (see my *big* post above for more details).
- Preinstalled bloat (automatic checking for updates, crash reporter, software center - easily uninstallable/replaceable with Porteus specific stuff - after the uninstallation of those, my Arch's XFCE is identical with Xubuntu's, of course I have tuned both in the same way).
- Lots of derivatives. This is a consequence of high quality desktop packages + lots of ppa's, lots of ppl want a less bugs + lots of readily-available software for their respins. Many liveCD's using Ubuntu base? Yes. Many of those using aufs/modules the way Porteus does? None. (Again, see my big post for what IMHO are Porteus' defining characteristics)

Alternatives:
- Debian. Stable. Not as user-friendly. Mixing unstable/testing with stable not always a good idea.
- CentOS. Super-stable 10-year support cycle. Not very desktop-oriented.
- Fedora, OpenSUSE, Gentoo - don't know haven't used.
- Arch, if aiming for more experienced user base/community.

User avatar
fanthom
Site Admin
Site Admin
Posts: 4547
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: The future of Porteus

Post#208 by fanthom » 06 Jan 2016, 15:32

So what would the advantages be of an Ubuntu based Porteus over arch?
Good points mentioned already - just to add few:
- Ubuntu LST version is released every two years which is a good thing IMO. Point releases for LST brings updated kernel and Xorg stack.
- every Ubuntu version is released according to schedule so you could plan things
- maintenance point of view: rolling release distros requires more testing to avoid breakage (ABI/API changes)
- commercial point of view: companies would trust Ubuntu LST (as it runs on many servers and probably even supercomputers) more than Arch or Manjaro (i know Desktop edition aims for regular users more than companies but still)

Just my two cents.
Please add [Solved] to your thread title if the solution was found.

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#209 by dimx » 06 Jan 2016, 18:41

- Ubuntu LST version is released every two years which is a good thing IMO. Point releases for LST brings updated kernel and Xorg stack.
Small addition: The original LTS kernel get support for the whole 5-year lifecycle. Additionally, new kernel package (tagged appropriately) is released for LTS version every 6-months (point releases as was mentioned) and supported for 9 months.

Jack
Contributor
Contributor
Posts: 1063
Joined: 09 Aug 2013, 14:25
Distribution: Porteus 3.2.rc5 Mate 64 bit
Location: Marysville, OHIO USA

Re: The future of Porteus

Post#210 by Jack » 06 Jan 2016, 19:24

I ran Mint Linux for awhile and the only way it ran good was you have to install it. If you ran it live it was slow or lockup and it was 1.4gb in size. And to install a program you pick it from a list but they do have a lot to pick from. So If we change Porteus (Slackware) it should be Arch Linux. That my 0.02cents. And that all I have to say about it.
I just like Slackware because I think it teach you about Linux to build packages where Ubuntu is like Windows you just install programs you want.

Post Reply