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.
donald wrote: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?
Suggestions/corrections/additions are always welcome.
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..
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...
Please add [Solved] to your thread title if the solution was found.
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.
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.
Please add [Solved] to your thread title if the solution was found.
fanthom wrote: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.
Suggestions/corrections/additions are always welcome.
@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.
Please add [Solved] to your thread title if the solution was found.
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.
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.
No intelligence, no life and no information can exist without prior intelligence, life or information (in place where things change and time is running).
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.
How do i become super user?
Wear your underpants on the outside and put on a cape.
"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
Please add [Solved] to your thread title if the solution was found.
fanthom wrote: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?
