Where the puppylinux 9 should focus on?.

[wanderer]

hi all

since this is a thread on puppy's future
i think this an appropriate post

i am using BionicPup32
and it is a masterpiece
so the woof-ce system is producing great work

however puppy should not limit itself to only 1 build system

s243a is working on what i believe is a truly groundbreaking system

as i understand it it will consist of

1. a core

2. a package manager that can download applications from various sources and attach them to the core

since the core will be derived in some measure from pupngo
it will be a puppy

this will allow the fast and easy building of unique distros

and one will only need to maintain the core and the package manager
to maintain the project

also it would allow non gurus to participate
because they would only need to run the package manager
to build a distro

you could make the recipe for the core and the specific build into a file
so they were reproducible

and you could instruct the package manager to save the downloaded components in a directory
so that you would not need to download everything again for each build


i hope i didn't offend s243a by mentioning this but it is just too extraordinary to not advertise

wanderer

[wiak]

[s243a]

I haven't voted on this poll because I feel that I could argue for or against each option and this leaves me feeling that this poll cannot capture the important nuances. Wiak's comment though captures somthing that I think is quite important.

Anyway, if Puppy remains in its inflexible woof-CE-dictated-format, other distros will naturally appear on the forum, which will move the game ahead (despite their lack of overall acknowledgement/visibility/promotion on the forum where they were created by its members) - already happened of course with Pussy-Linux -> DebianDog series and more since. Puppy development suffers because of inward-looking attitude (despite it relying otherwise and elsewhere on upstream repos...).

Note that this is less of an issue for both Fatdog64 or EasyOS since they are built from source but if one is providing a large repository of packages there are a lot of compile options that one can optimize so perhaps even when compiling from source there is some basis of default compile options.

Anyway, why this is important to me is that when I tried installing synergy via tahrpups package manager, I got way too many unneeded systemd dependencies and worse yet these dependencies might have been incompatable with my system. l can only imagine the situation getting worse with the large repos and given that WoofCE has dropped support for some linux varients, I worry that relying too much on only a few major linux variants puppy is heading in the direction of much unneeded bloat.

The truth is though that by the time that you install a top of the line browser you will probably end up with a lot of bloat no matter what you do but this doesn't mean that we should not do our best to try to avoid this situation.

I've found some modern version of puppy (e.g. Xenial and Slacko64.6.9.9.9) run very slow on my computers and others run much better like "dpup strech" and "uPup Bionic Beaver". I feel that modern puppies are pushing the edge of my system where some pass and some are slughish where older versions run much swifter.

It is inevitable that newer software will demand more from a system but we shouldn't be complacent about it. Looking for the bottle necks and bloat should be an important goal. In this vein I like the philsophy behind Slacko 5.7.2 Community Edition and perhaps the optimizations made in it would solve the problem of some newer puppies having slugish performance on my computer.

That said "Slacko 5.7.2 Community Edition" doesn't address the question about what binaries or alternatively source we should use but I do believe that one goal of the puppy build system (currently woofCE) should be to provide enough flexiblility so that if someone needs to use a repo with less bloat than the few major version of linux repos that woofCE currently supports than they can easily do so. Granted one doesn't necessarily need woofCE to do this but so long as the mantra here is "official puppy is a woofCE build" then in my opinion it should be a priority for woofCE to support repos with less bloat than the major distros.

As a final note I believe that woofCE needs to stay flexible enough to support old hardware so please don't for instance drop boot code which provides support for older hardware just to make the code a little cleaner.

[darry19662018]

Over the last week I have been somewhat dismayed at how pulseaudio and systemd are creeping into puppy - for example stretch has pnmixer instead of retrovol an app that doen't rely on pulseaudio I also see the dependency of systemd with xorg server this very bad. Puppy is an independent distro and should in future avoid this rubbish.

I would like to see T2 returned to Woof CE to build a slimmer pup like Racy, 4.31 etc as well Devaun which is frankly a better base than systemd infected debian and ubuntu.

Also look into other distros like alpine and void linux for bases.

[wiak]

Also look into other distros like alpine and void linux for bases.

I'm using void everyday at the moment - and, really, the underlying system methodology (runit) and its amazingly good but specially tailored repo offerings seem like a dream fit for what would be a great upstream repo for Pup builds (assuming it was too difficult to automate compiling its own repos via T2, which continues to be developed, or OpenEmbedded, or BarryK fork of that as used in EasyOS as far as I remember reading, which, I can't help but feel, is a more interesting distro than Puppy itself nowadays).

As provided, Void has that big limitation that it is really expected to be installed as a full install - so it is just waiting for someone to come along and either take its live CD version and implement layering/persistence and extra sfs loading capabilities (maybe someone done this already? - I can't find info on that, though I am experimenting with it myself), or... to create a Puppy version that utilizes its underlying non-systemd boot system and its repo offerings.

I too am disillusioned with Puppy using Debian/Ubuntu/Slackware pretty much only nowadays - like I said, when it comes to Debian/Ubuntu the Dogs do that almost perfectly already. Pups were supposed to be slim, fast, and easy to use and easy on system resource use - I really think their current development is way off track and whilst lots of code in woof-CE could be re-used, I really feel the overall build system should be re-invented/re-thought. Again, I wonder if EasyOS mechanisms should be examined more closely and integrated into Puppy - albeit with a radically different commandline driven build system. Sorry, but I really don't like woof design. I like Debian debootstrap ease-of-use and functionality though and how it can be added to via later stage chroot manipulations. Having said that, woof-CE can be usefully used with chroot towards end of build too as I documented here:

http://www.murga-linux.com/puppy/viewto ... 512#966512

wiak

[s243a]

Over the last week I have been somewhat dismayed at how pulseaudio and systemd are creeping into puppy - for example stretch has pnmixer instead of retrovol an app that doen't rely on pulseaudio I also see the dependency of systemd with xorg server this very bad. Puppy is an independent distro and should in future avoid this rubbish.

I would like to see T2 returned to Woof CE to build a slimmer pup like Racy, 4.31 etc as well Devaun which is frankly a better base than systemd infected debian and ubuntu.

Also look into other distros like alpine and void linux for bases.

Have you tried the following puppy?

puduan-7.0.0a1 (Devuan Ascii) woof-ce testing

perhaps it might help somewhat address these concerns

[darry19662018]

Yes I have - buggy but nice. Like I said development in CE was dropped - a strange decision.

[mavrothal]

[Lobster]

a script to build and remaster cores sfs files and pets
so you could make one that has the stuff you want

How possible in coding terms is it to have Menu styles.

eg: Noob, Geek, Programmer, General use, Minimalist, Everything etc?

[darry19662018]

Over the last week I have been somewhat dismayed at how pulseaudio and systemd are creeping into puppy - for example stretch has pnmixer instead of retrovol an app that doen't rely on pulseaudio I also see the dependency of systemd with xorg server this very bad. Puppy is an independent distro and should in future avoid this rubbish.

I would like to see T2 returned to Woof CE to build a slimmer pup like Racy, 4.31 etc as well Devaun which is frankly a better base than systemd infected debian and ubuntu.

Also look into other distros like alpine and void linux for bases.

Have you tried the following puppy?

puduan-7.0.0a1 (Devuan Ascii) woof-ce testing

perhaps it might help somewhat address these concerns

Revisting Devuan 7.0.0a1 Nice version not as good as Mushers version 6 but defo worth fiddling with as it is quite stable. No firewall so installed Peasy firewall monitor.

[Puppyt]

Ok I just voted for "All/None of the above".

I have been thinking today about comments I think from both/either wiak and/or darry19662018's similar comments elsewhere on the forum about Puppy's apparent trend recently to follow the "big dogs". Ah - I think it was in the (EDIT!) "I'm sick of systemd and PulseAudio..." thread. Through a bit of meandering earlier I found a diatribe from Stallman (RS) regarding Ubuntu as spyware (https://www.youtube.com/watch?v=CP8CNp-vksc), within a broader consideration of FOSS and "ethical" software, as it pertains to his definition of "freedom". I am pretty sure it has been nosystemdthanks who has mentioned a similar ideal with his associated goals on the Puppy forum (his signature had a link to a well-considered manifesto, in my opinion). So - without fully groking the implications of "proprietary blebs" (blobs?) of code in the Linux kernel etc., my vote is for a fully "ethical" /GNU Puppy with all those historical proprietary trappings removed. Puppy is already an environment of pretty decent ethics in my regard, regarding its existing and hopefully expanding reach over a burgeoning range of hardware (EDIT) otherwise consigned to technological obsolescence 'cos it won't run the latest version of Windows (coming soon to your old smartphone?). Why not go the whole hog? or dog? for a *fully* Ethic Pup base?

[mavrothal]

my vote is for a fully "ethical" /GNU Puppy with all those historical proprietary trappings removed

Something like that (4 links) was available few years back, and would be easy to repeat with trisquel 8/9
The many hardware incompatibilities and the lack of many audio/visual codecs however, make it a very limiting OS and is probably the major reason that librepup did not fly.
Would be easy to redo as it is basically an ubuntu-based pup, but did you check if trisquel 8 actually works on your hardware?. If it does not, a libre/ethical/free pup will not either.

[Puppyt]

Thanks mavrothal, for pointing those out for me. Actually I rushed my comment off last night and was concerned it would expose my general ignorance of "true" "free" software, free-dom as considered by the FSF, and other high-end philosophical matters. I guess my grasp is not so much puritanical, but rather an issue of transparency that I feel that future Puppy could adhere its core values towards. Reading through the list of choices in the poll, I had the impression that most were actually emergent features of the existing modular model of Puppy.
And, with a little more poking around under stones, I see that Stallman also acknowledges/had acknowledged the impracticalities of doing without proprietary blobs in hardware drivers. (What about getting the hardware manufacturers to 'surrender' their code to the GPL??) Great to see that Trisquel is still being developed - I only ever had sideways glances at Iguleder's later projects - they seemed too highbrow for my needs for just getting on with integrating with all my MicroSoft-bound associates, as Puppy already provided for me.
So as an end-user and not a developer who has better grasp of the free-dom concepts and practicalities, I apologise for my muddled interpretation of the issue that nonetheless appeals to my philosophical bent: IS THERE AN ALTERNATIVE? That's essentially how I came to Linux via Puppy - realising that Windows was a loose framework to support shadowy third-party wheeler-dealings that I no longer wanted to buy into. I really cannot stand the doublespeak of Microsoft's "security" updates, when by the very nature of its deliberately faulted design the overall performance of my modern hardware is eroded away from its true potential.

[s243a]

Thanks mavrothal, for pointing those out for me. Actually I rushed my comment off last night and was concerned it would expose my general ignorance of "true" "free" software, free-dom as considered by the FSF, and other high-end philosophical matters. I guess my grasp is not so much puritanical, but rather an issue of transparency that I feel that future Puppy could adhere its core values towards. Reading through the list of choices in the poll, I had the impression that most were actually emergent features of the existing modular model of Puppy.
And, with a little more poking around under stones, I see that Stallman also acknowledges/had acknowledged the impracticalities of doing without proprietary blobs in hardware drivers. (What about getting the hardware manufacturers to 'surrender' their code to the GPL??) Great to see that Trisquel is still being developed - I only ever had sideways glances at Iguleder's later projects - they seemed too highbrow for my needs for just getting on with integrating with all my MicroSoft-bound associates, as Puppy already provided for me.
So as an end-user and not a developer who has better grasp of the free-dom concepts and practicalities, I apologise for my muddled interpretation of the issue that nonetheless appeals to my philosophical bent: IS THERE AN ALTERNATIVE? That's essentially how I came to Linux via Puppy - realising that Windows was a loose framework to support shadowy third-party wheeler-dealings that I no longer wanted to buy into. I really cannot stand the doublespeak of Microsoft's "security" updates, when by the very nature of its deliberately faulted design the overall performance of my modern hardware is eroded away from its true potential.

A compromise might be to move the non-free stuff out of the base sfs and into another sfs such as the Adrv or one of the "extra sfs".

[mavrothal]

I guess my grasp is not so much puritanical, but rather an issue of transparency that I feel that future Puppy could adhere its core values towards.

Which part of official woof-ce built puppies you think deviate from transparency that puppylinux 9 should be more vigilant about?

[dancytron]

I guess my grasp is not so much puritanical, but rather an issue of transparency that I feel that future Puppy could adhere its core values towards.

Which part of official woof-ce built puppies you think deviate from transparency that puppylinux 9 should be more vigilant about?

The script that builds it is open source, human readable, and available for anyone to download who want to, so I don't know how you could possibly make it more transparent.

FSF ideals sound nice, but in the end they produce software that doesn't work for a lot of hardware or with at least some software.

[Puppyt]

Excellent points, thank you s243a (edit soz!), mavrothal and dancytron. The seclusion of proprietary blebs in an optional (read, "probably essential") sfs might provide a conscientious end-user with the opportunity to operate within a wholly *libre* or Trisquel-like ethical software environment. Of course, as soon as they install or use proprietary software - in my case, SoftMaker Office - then the ideal is rattled - but at least the end-user has the fully informed choice to make their own balance.

I really like the fact, and I think it is a major strength - that woofCE is fully transparent, adjustable and documented throughout. That is, as I understand it - as I inferred with my earlier use of 'grok', I'm really a stranger in a strange land when it comes to even that level of coding. That fact that the Puppy base has always been DIY-friendly by design is also a major "selling" point. It could be as simple as swapping kernels, constructing your own SFS archives, and so on. There's that invitation, if you will, for the "user" to be an active element within the entire process that underlies one of the reasons why I find Puppy so engaging (re the "...just have fun" option in the poll) - even if I don't quite have the time to follow through on finding the elegant solution to a given issue. Perhaps that is the essence of where I feel Puppy-9 should head - what other linux distro gives its user full rein to go off the leash, without the throwbacks to "administrator-level permissions"? Oh - might be useful to have multi-user capacity and administrator-level securities to be included in an optional SFS, so that another "complaint" about root access can be defused. Real choice, that is

[darry19662018]

Mmmmm interesting idea Puppyt for separating proprietary firmware from main sfs. My main concern though was how systemd and pulseaudio are creeping into puppy development especially systemd. I have seen how other distros have struggled to keep systemd out but as packages become more dependent upon it the more difficult the "resistance" is.

I dismayed was the use of gnome-mixer in Stretch and pnmixer when we have the excellent retrovol which isn't dependent on systemd.

So I'll say the one more time developers beware of the systemd hook and avoid it as much as possible. By the way I am not criticizing the quality of Stretch just the Systemd inclusions and pulse-audio.

[mavrothal]

Mmmmm interesting idea Puppyt for separating proprietary firmware from main sfs.

In some resent puppies (all by PB) the firmware is on a separate SFS. Just rename it so will not load and see if your system will work.
However, there are still blobs and non-free stuff. Foremost the grub/grub2/grub4dos that boots the machine and then most of the audio/video codecs. Other things that tisquel also purges from Ubuntu are not usually in puppies.

My main concern though was how systemd and pulseaudio are creeping into puppy development especially systemd.

Would you mind defining creeping? AFAIK neither puppylinux not fatdog use systemd to manage the system. Only some(?) (all?) debiandogs do, I think.
Puppylinux/fatdog just have a library that is needed for many applications to run.
If down the road these applications also require systemd to control the machine, then we'll be in real trouble. Hopefully this will not happen or if it does would be possible to bypass.

[wiak]

AFAIK neither puppylinux not fatdog use systemd to manage the system. Only some(?) (all?) debiandogs do, I think.

It was an early principle in the design of the Dogs that the user was given choice what boot system they wanted to use, which I personally like since not being able to experiment with systemd would leave me with no technical knowledge about it and leave me ignorant on how to set it up should I happen to be on say a full RedHat or Ubuntu system etc. As far as I remember, in the Dogs it is simply a matter of a kernel boot parameter to determine whether sysVinit or systemd will be used. Certainly it seems, from what I've read, that systemd functionality more generally is becoming expected to be present so may become a dependency of other system components - which will become a problem for any system attempting to stick to sysVinit or some other init boot mechanism. Choice is good though since user doesn't otherwise need to use systemd when they do not want to (and they have the choice should circumstances demand it).

Pulse-audio is the other issue of course, but not such a major one I feel. I presume apulse acts as a fake pulse-audio API but passes control onto alsa directly thereafter - that kind of solution appears to be the best in terms of satisfying pulse-audio dependency when actually just wanting to use alsa directly; but again choice is good - either way, a standard audio application interface (which is what pulse-audio aims to be) makes it easier for app developers (such as firefox).

Actually, I do use actual pulse-audio in my Dog system, and systemd as it happens... but not for any preferential reason - just working for me, so can't be bothered cutting them out.

When I'm running Void Linux, I'm using its default runit system instead of systemd, which works nicely. I generally just quickly install pulse-audio there when I want sound to work with firefox, though I could use apulse instead of course, but don't feel the need to fake it.

wiak