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.
-
Bogomips
- Full of knowledge
- Posts: 2564
- Joined: 25 Jun 2014, 15:21
- Distribution: 3.2.2 Cinnamon & KDE5
- Location: London
Post#61
by Bogomips » 21 Oct 2014, 01:36
Rava wrote:Modified Bogomips Wish:
Deactivate like now, with naming the processes that still use the module, but with added PID to kill of someone wants to do so. With warning in bold and red that killing programs could cause system instability, data loss and that jazz...
No need to complicate situation. This deactivate would be used only by those aware of the risks, and who would already have saved data in jeopardy. All processes would be lost anyway, should one have to reboot.
However on the upside, just run scanner, constructing list of PIDs requiring killing, hand over to deactivate, module freed and no relevant processes lost. Should it prove viable, then could be extended from just one package to an entire bundle. Would mean bundles could be inserted and removed with ease. (For starters to minimise risk while proving viability would be sensible to be in always fresh mode with copy to ram and without changes file, as I normally run)
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
Bogomips
-
fanthom
- Moderator Team
- Posts: 5588
- Joined: 28 Dec 2010, 02:42
- Distribution: Porteus Kiosk
- Location: Poland
-
Contact:
Post#62
by fanthom » 21 Oct 2014, 08:46
bit too dangerous to my liking. i'm worrying it may cause changes corruption.
please find a better way, some hints can be find in this old thread (Porteus 0.9
):
viewtopic.php?f=41&t=200Please add [Solved] to your thread title if the solution was found.
fanthom
-
phhpro
- Full of knowledge
- Posts: 543
- Joined: 10 Nov 2013, 20:35
- Distribution: .
Post#63
by phhpro » 23 Oct 2014, 22:46
...
Last edited by
phhpro on 04 Feb 2016, 02:04, edited 1 time in total.
phhpro
-
fanthom
- Moderator Team
- Posts: 5588
- Joined: 28 Dec 2010, 02:42
- Distribution: Porteus Kiosk
- Location: Poland
-
Contact:
Post#64
by fanthom » 24 Oct 2014, 06:39
just in case: How about NTP.
please have a look on 3.1 rc1 changelog as i have implemented ntp based solution already
Please add [Solved] to your thread title if the solution was found.
fanthom
-
phhpro
- Full of knowledge
- Posts: 543
- Joined: 10 Nov 2013, 20:35
- Distribution: .
Post#65
by phhpro » 25 Oct 2014, 01:31
...
Last edited by
phhpro on 04 Feb 2016, 02:04, edited 1 time in total.
phhpro
-
francois
- Contributor
- Posts: 6292
- Joined: 28 Dec 2010, 14:25
- Distribution: xfce plank porteus nemesis
- Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.
Post#66
by francois » 27 Oct 2014, 22:17
@Peter:
Are you announcing us that you are leaving Mexico?
Prendre son temps, profiter de celui qui passe.
francois
-
Kriss
- Samurai
- Posts: 135
- Joined: 06 Jul 2011, 07:07
- Location: Russia
Post#67
by Kriss » 06 Nov 2014, 07:12
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".
Suggestions/corrections/additions are always welcome.
Kriss
-
fanthom
- Moderator Team
- Posts: 5588
- Joined: 28 Dec 2010, 02:42
- Distribution: Porteus Kiosk
- Location: Poland
-
Contact:
Post#68
by fanthom » 06 Nov 2014, 09:37
or maybe we could drop 32bit arch entirely?
see Ubuntu:
http://www.phoronix.com/scan.php?page=n ... px=MTgxOTQ
that would definitely lower overhead on the dev side and simplify things.
perhaps we could froze 32bit on 3.1 release and deliver only security updates provided to Slackware-14.1 by Pat.
what do you guys think?
Please add [Solved] to your thread title if the solution was found.
fanthom
-
donald
- Full of knowledge
- Posts: 1985
- Joined: 17 Jun 2013, 13:17
- Distribution: Porteus 3.2.2 XFCE 32bit
- Location: Germany
Post#69
by donald » 06 Nov 2014, 13:21
@ fanthom
you may take a look at the server-logs...how many 32bit downloads have been done...
That should give you an idea whether 32-bit is still important.
donald
-
francois
- Contributor
- Posts: 6292
- Joined: 28 Dec 2010, 14:25
- Distribution: xfce plank porteus nemesis
- Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.
Post#70
by francois » 06 Nov 2014, 17:33
... that would definitely lower overhead on the dev side and simplify things ...
What is good for the developpers is good for us all.
... we could froze 32bit on 3.1 release and deliver only security updates ...
This could be called a very good after sale service.
Prendre son temps, profiter de celui qui passe.
francois
-
tome
- Contributor
- Posts: 657
- Joined: 26 Jun 2013, 14:03
- Distribution: x64 Openbox
- Location: against russian attacks and lies
-
Contact:
Post#71
by tome » 08 Nov 2014, 21:14
perhaps we could froze 32bit on 3.1 release and deliver only security updates provided to Slackware-14.1 by Pat.
what do you guys think?
I agree, version 3.1 is probably last that we can grab ready-made LXDE module and it would be something like Long Term or Extended Support Release.
You have mind and feelings. Be wise and clever.
tome
-
donald
- Full of knowledge
- Posts: 1985
- Joined: 17 Jun 2013, 13:17
- Distribution: Porteus 3.2.2 XFCE 32bit
- Location: Germany
Post#72
by donald » 08 Nov 2014, 23:53
drop 64 bit...32 bit fits all..
..up to now has 64 bit no real Advantages..
Last edited by
donald on 09 Nov 2014, 02:14, edited 1 time in total.
donald
-
Bogomips
- Full of knowledge
- Posts: 2564
- Joined: 25 Jun 2014, 15:21
- Distribution: 3.2.2 Cinnamon & KDE5
- Location: London
Post#73
by Bogomips » 09 Nov 2014, 01:37
Afraid not quite au fait here. Thought common consensus of the web was that, without a compelling reason to move to 64 bit, one is better off sticking to 32 bit.
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
Bogomips
-
donald
- Full of knowledge
- Posts: 1985
- Joined: 17 Jun 2013, 13:17
- Distribution: Porteus 3.2.2 XFCE 32bit
- Location: Germany
Post#75
by donald » 09 Nov 2014, 11:54
@ fanthom
The comment was not meant seriously, but true.
OK.lets see:
I looked at the results...here one second ,there one second ..not sooo much
and in general, benchmarks have nothing to do with the daily workflow...
I agree when you say that maintaining 2 archs of porteus
claimed more of your free time as you like.
But I think more about all the not so rich countries / people
who would lose an opportunity to use their hardware.
and what about the portability?
"hey donald, please help me,my system crashed.";..sure, wait a moment...Oh you're using a 32bit PC....I'm sorry, my porteus usb-flash won't boot here...sorry"....
donald
