@tonio
Links appreciated, just the kind have had in mind to look for.
Nemesis of Porteus
Shifting Goalposts
II. Different Directions
Quality vs. Quantity
Have just a few apps, not more than 20, probably nearer 10 in number. However require them to be just about the very latest version, which at the moment they are. Also, thanks to neko, running on 4.2.5 just about the latest stable kernel. Consequently been able to dispose of nvidia driver, as nouveau is up to the job in latest kernels. Managed to bump C++ library to version needed by most of newer apps,
Have GTK+ VERSION 3.16.7 one of the latest versions of GTK+3 from Arch. This has systemd dependencies, which are satisfied by ver. 224 systemd module weighing in at just over 12 MB, with all Porteus dependencies.
(As this module at graphical level, does not seem to interfere with system.) Have latest version of Handbrake and Nemo
(cinnamon file manager) from Arch, both of which require late version of gtk+3. Also able to run gtk3-demo program.
Just had the one system crash this year, and that was when trying to run a java applet, other than that, two or three times not woken up from sleep. On previous live systems was not unusual to expect a crash or two of system every other day. Able to booti from iso file on hdd and run in ram AF using 30% of available 880 MiB ram with cpu clocked at 800 MHz. Given the limited resources, have no problem with video playback, etc. Think that's as good as it gets!
PaleMoon Firefox Divide
The scenario I would like to present is somewhat akin to the PaleMoon Firefox Divide. The bells and whistles brigade going to Porteus 4.0, while those who want a Porteus, as they know it, try to make the ride last just a little longer.
Dependencies Resolution
In the matter of resolving package dependencies, the pkgs.org resolver should able to get the Arch dependencies which can thereafter be fed into neko's sausage machine which produces a module, given a list of Arch of dependencies, should one be not too bothered about what goes into said module. The rpm and deb dependencies, which the resolver finds will however have to be modularised by hand.
This just leaves dependencies for Slackware packages, which cannot be properly dealt with by the resolver procedure, owing to inadequate documentation in pkgs.org.
brokenman wrote:Will USM and the tools to support it be maintained?
No it wouldn't.
Not stated was whether code of same could be released for maintenance by someone who has delved into the workings of usm, here having in mind, cttan.
KnallKopf wrote:It is a littlebit crazy that where Porteus is perfect (the USM is a great work) the evolution stops.
Crying shame to let USM die. At a minimum would be worth just to keep usm ticking over by updating database when necessary.
Upcoming Slackware Release
- Kernel module. Maybe neko could oblige by providing one.
- Core module. Not so au fait here. Maybe within neko's area of expertise, or matter of live scripts.
- Xorg module. Can't think offhand of anyone who can do that. Live scripts?
- As far as fitting on a desktop, could claim experience in that direction having done stints in system software development, system software support and firstline support in a somewhat software engineering capacity (learning by doing, the buzz phrase), in the level between the core system and the user application, reaching into both core system and user application.
And it seems there will remain quite a pool of experience and expertise, which one could tap, for guidance by any attempt to help with installing a desktop. Starting with the simplest desktop and then progressing on to more complex ones. Help being restricted to hobby level (not f/t).
Haven
Ecocomputing wrote:Q: Which of the lightweight linux distributions, which also run entirely in RAM do I best use ?
A: The best distribution for you will depend on your own preferences. TinyCore Linux for example is extremely small (<10MB) and lightweight, uses FLWM window manager and relies solely on xvesa drivers (not X.org graphics drivers) so it will work on even computers where you could have graphics problems with. However, for most it's just too spartan. SliTaz is only a bit bigger (40MB) and has more functionality, ... (Openbox as Window manager, own package manager -TazWeb/tazpkg-, ...). Antix is all ready quite a bit bigger (690MB) but is much more familiar for debian-refugees (semantic package manager, ...). LXLE and Porteus are bigger yet, have the LXDE window manager, and are easier for Ubuntu-refugees. Note finally that linux distro's sometimes get discontinued. So this list of distro's needs to be viewed as a guideline. When you decide to change to a lightweight linux distro, it's best you first research the current distro's available by checking out the appropriate wikipedia articles.
Striking a Blow for a Greener Environment.
As distros get more and more power hungry one can expect more and more refugees with slightly outdated h/w, or disabled ecologically-sound computers (usually hdd u/s) who will want to make a go of it on lightweight distros. If they are prepared to go this far, then it is most likely they would be prepared to put up with distro of different nature from that to which they were accustomed, and to learn the ropes, and they would normally be of the more experienced variety, who would not throw in the towel at first sign of difficulty.
Delegation
brokenman wrote: From our (Fanthom and I) experience it is best to wait until we see a user working hard in the community and doing stuff in the development section first, and then approaching them to see if they would like to join the team.
IMHO an unaffordable luxury at this juncture. Do helpers have to be on the team if it is just a stopgap measure to breach the current difficulty?
brokenman wrote:It is a complete waste of time (that we don't have) to teach someone all the ropes only to have them leave the next year. Even saying straight up 'We need developers. Apply within' just hasn't worked. Usually we will watch strong participants in the community that are developing something alone
Alright in the long run, but at the moment there appears no prospect of a long term perspective.
brokenman wrote:and see if they stay. Even then, the person has to understand what they are committing to.
Then again, how long is a piece of string?
Surely dedicated volunteers do not have to be on the team. They can just help out with simple or time-consuming aspects of the work.
(Some two-three months before release date we received code from the Italian section. It was full of errors of the kind, just recently come across: edit file a, then copy file b to file a. Just the one column of assembler extending over many, many pages with not a single comment. Clearly used trainee programmers for the job. Had our hands full correcting logical errors, left the other parts of code untouched with all the superfluous instructions. Managed to get debugged for release, terribly inefficient but worked. Come next release code from Italy of very different nature, with very little to correct, and none of the unnecessary instructions. Clearly programmers replaced or improved.The design was important, and how bad the code was really did not matter just as long as it could work the first time!) 
Really doesn't matter if someone helps out and code not so tight or slightly erroneous, as long as it can be got to work within a tried and trusted design. Next time round person either improved or replaced, but time has been bought and the design will win through.
Reservation
Having participated in bringing out major release of an os, am familiar with all the brouhaha that goes with it. Consequently with all due respect to brokenman for his dedication and with gratitude for help rendered, my major concern, apart from reservation over lack of extensive testing over extended period of time, is stability. And I cannot in all honesty regard the Arch way into uncharted territory a viable proposition.
Brings to mind a Czech short I once saw. It concerned two mice going at it hammer and tongs, solving the most complicated integral equations on a blackboard. Then along comes a cat, and with a smirk on his face writes 1+1=2. Next thing mice out of the picture! All that's left is cat with contented look on face licking his chops!
KnallKopf wrote:
For example it is not good when the distrubition depends only on one Man. When he makes a wrong decision or leave the project.
Or worse still but nicer if brokenman smitten: ravishing Brazilian beauty cross his path, and brokenman, at the drop of a hat, forsake all his computers for love!
Then 'twill be
finito de la musica, passato de la fiesta (apologies to beny if got it wrong)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
