Wishlist for porteus 3.1

[Kriss]

drop 64 bit...32 bit fits all..
..up to now has 64 bit no real Advantages..

Some people (like me) use it on systems with more than 4Gb of RAM. 95% of the time it's 8 - 16 Gb in my case.
AFAIK, most 32bit programs have the same limitations.
P.S. PAE kernel doesn't work on some of the CPUs (as I was told when I asked for it here).

P.P.S. Sadly, 32 bit version is sometimes needed for older CPUs (I usually have both versions on one USB flash).

@fanthom You're looking for a ways to reduce your workload (sorry, didn't find a better word)? Or you're just curious?

[donald]

Hi Kriss
Yes you're right, some very old hardware (PII + amd k6) may not support PAE very well, if at all.(some Pentium M processors "Centrino"too)

But I believe that PII's and similar are attached onto Motherboards
which do not support such a lot of RAM.(no need for a PAE kernel) and I'm in doubt that such old Hardware is able to run any modern OS (like porteus)

To have both versions on one usb-flash is nice...as long as we get both versions.. :wink:

[Bogomips]

Ubuntu 14.04 LTS 32-bit vs. 64-bit Performance

Usually the only caveat in not using a 64-bit Linux image is if running a system with less than 2GB of RAM.

PC bit over 5 yrs old. Getting on famously with Porteus on just under 1GB ram.

Boils down to: versatility vs. velocity

[fanthom]

no worries guys - 32bit arch is not going to be dropped anytime soon. that would be a shoot in our own feet as many people recommend porteus for older PCs. i was just wondering the reaction of the community. was expecting plenty of emotional comments but got quite calm and constructive feedback.

thanks a lot for that.

@Kriss
I'd like to suggest to rename all x86_64 core modules so instead of, for example, two 05-devel modules we'll have "05-devel.xzm" and "05-devel64.xzm" Same for "vmlinuz" and "initrd.xz".
that would require:
- remembering of adding '64' bit to relevant component (tweaking of dev scripts?)
- updating to the bootloader configs/wizard/iso creation script
- doc updates (biggest task)
i have asked for this brokenman as we agreed that benefit is quite low so it's up to the users to keep archs separately.
sorry about that.

You're looking for a ways to reduce your workload (sorry, didn't find a better word)?
Ahau left the project so Jay and me have to do approx 33% more work than before so the answer is yes - i'm trying to reduce workload wherever i can (or just 'do things smarter' like brokenman said). that's why i did not bother with proprietary drivers for rc1/rc2, we never provide language files before userland is frozen, LXDE->RazorQT merger comes handy (one DE less to maintain), etc...

[donald]

@ fanthom
--> 32bit arch is not going to be dropped anytime soon <--
Many thanks for this statement.

the workload:
I would get along well with a longer release cycle of porteus.
A new slackware version = a new porteus release

[dstarke]

The most obvious solution is a combined 32/64 bit kernel (selectable at boot) with 32bit software. The main advantage of the 64bit kernel is that it allows addressing a larger memory space and so many more programs will run simultaneously. While the kernel runs somewhat faster at 64 bit, PROGRAMS generally do not and some actually run slower. The only programs which will benefit from being compiled for 64bit are those which must keep large (huge, gBs in fact) amounts of data in memory.

It seems to me that having the universality of both 32bit and 64bit kernels available (making Porteus a truly portable OS) while using the same installed program base (to save replication and to ease upgrading of programs) overrides any (if any) small gains in speed by running 64bit compiled programs.

So my suggestion is to provide a truly universal disk which will run on any machine and which utilizes all the memory on advanced machines. This has been done in KNOPPIX very sucessfully.

TIA for your consideration.

[fanthom]

A new slackware version = a new porteus release
slockware releases rarely, sometimes it's a year and sometimes 18 months.
i hope we will be able to preserve 2 releases per year, if not then 2 releases per one Slackware.
will see.

The most obvious solution is a combined 32/64 bit kernel (selectable at boot) with 32bit software.
and then we can forget about proprietary drivers for 64bit PCs. if you go through the last few threads on the forum you'll see that many people still use them.
i think we will stick to current scheme - maintaining 2 archs is not that hard as all our scripts/tools are 'noarch' at the moment.

thanks guys for your input.

[Kriss]

no worries guys - 32bit arch is not going to be dropped anytime soon. that would be a shoot in our own feet as many people recommend porteus for older PCs. i was just wondering the reaction of the community. was expecting plenty of emotional comments but got quite calm and constructive feedback.

thanks a lot for that.

@Kriss
I'd like to suggest to rename all x86_64 core modules so instead of, for example, two 05-devel modules we'll have "05-devel.xzm" and "05-devel64.xzm" Same for "vmlinuz" and "initrd.xz".
that would require:
- remembering of adding '64' bit to relevant component (tweaking of dev scripts?)
- updating to the bootloader configs/wizard/iso creation script
- doc updates (biggest task)
i have asked for this brokenman as we agreed that benefit is quite low so it's up to the users to keep archs separately.
sorry about that.

You're looking for a ways to reduce your workload (sorry, didn't find a better word)?
Ahau left the project so Jay and me have to do approx 33% more work than before so the answer is yes - i'm trying to reduce workload wherever i can (or just 'do things smarter' like brokenman said). that's why i did not bother with proprietary drivers for rc1/rc2, we never provide language files before userland is frozen, LXDE->RazorQT merger comes handy (one DE less to maintain), etc...

Well, sorry for asking. It seemed like a useful idea.

[fanthom]

@Kriss
there is no need to feel sorry - this is a 'wishes' thread
users role is to post ideas and our role is to filter ones which:
a) are useful
b) can be implemented
d) does not require tremendous effort on our side

this is how it works.

[tome]

My suggestion is to change site content from:

Code: Select all

Use semicolons (;) as command separators with no spaces. If you need to use spaces in the command line, replace them with '~'. Example: 'guiexec=firefox~kernel.org' will open the firefox browser on the 'kernel.org' website.

to

Code: Select all

Use semicolons (;) as command separators with no spaces. If you need to use spaces in the command line, replace them with '~'. guiexec=numlockx~on;firefox~kernel.org' will turn on Num Lock key and open Firefox browser on the 'kernel.org' website.

at http://build.porteus.org/ -> Settings -> Advanced options

[Blaze]

Do you plan to add to USM these packages repositories (x86_64)?

Slackware packages (the base system packages and libs) :
http://slackware.mirrors.tds.net/pub/sl ... 64-current
http://mirrors.easynews.com/linux/slack ... 64-current
ftp://ftp.slackware.com/pub/slackware/slackware64-14.1/

Zenwalk specific packages (the Zenwalk Desktop, Zenwalk system tools, studio tools) :
http://download.zenwalk.org/x86_64/current/zenwalk
http://distro.ibiblio.org/zenwalk/x86_6 ... t/zenwalk/
http://zen-repo.meticul.eu/x86_64/current/zenwalk/

Alien Bob's packages (many extra apps, JRE, JDK, Libreoffice dictionaries, etc...) :
http://slackware.org.uk/people/alien/sb ... nt/x86_64/
http://taper.alienbase.nl/mirrors/peopl ... nt/x86_64/
http://www.slackware.com/~alien/sbrepos/current/x86_64/
http://mirrors.nix.org.ua/linux/slackwa ... nt/x86_64/

Studioware packages (alternative studio audio and video tools) :
http://www.studioware.org/files/package ... re64-14.1/

Probably some are present in USM.

[brokenman]

Slackware and alien are already present.

I see no reason to add zenwalk.

Studio will not be added. To many broken dependencies (already tested it).
I will eventually add slackware-current but this won't be for some time. It will require more maintenance time from me which I do not have at present.

[StefanO]

My wishes:
ddrescue in all versions,
continue the PXE,
an other method for donations than paypal ...

[fanthom]

"My wishes: ddrescue in all versions"
brokenman put some effort into the 'thin client' area so Porteus Rescue edition rather wont materialize soon despite that it was so promising project:
https://www.youtube.com/watch?v=R804iRA_dfw

perhaps i could maintain all cli rescue utilities in the core of the desktop edition: ddrescue, testdisk, extundelete (saved my ass big time last week), anything else? or maybe a 'rescue shell' itself could be added to it?
it would not add a much size to the ISO (few MB) and could be certainly a nice addition.
any comments?

"continue the PXE"
will be there

"other method for donations than paypal"
like for example?

thanks

[Ed_P]

perhaps i could maintain all cli rescue utilities in the core of the desktop edition: ddrescue, testdisk, extundelete (saved my ass big time last week), anything else? or maybe a 'rescue shell' itself could be added to it?

I like both those ideas.