Getting more users to use puppy

[sc0ttman]

Most Puppy users and even devs refuse to get involved in anything Git or GitHub

Pull requests are always welcome and mostly granted.
There are not many coming though....

Separate out all the puppy apps into their own reps then, and you will defo get more PRs in future...

Having them all in a mono repo blob, makes it so much harder to contribute.

Let's say I do a fix to the puppy installer... I don't have th option of pulling down the installers repo, making a feature branch, and doing a pull request on just that program... I cant even pull down the installer repo, build the program on its own... basic!

Instead, I have to pull down all of Woof-CE, make some changes in the installer program, manually copy them into some other place to test them, copy them back, and THEN do a PR of the whole woof-ce thing - making merge conflicts way more likely, changes MUCH harder to find, (let alone revert) and leaving the installer changes to be lost in the massive git history of the mono repo ...

Creating feature branches is essential to getting multiple devs working on a single code base, but the way woof is organised, that becomes almost impossible..

It's also imossible to create forks of individual puppy programs, cos they live in the mono woof-ce repo .. this slows down development as well..

I've literally never known any serious software project bundle all kinds of DIFFERENT changes (bugfix, new feature, breaking change, minor change) into a single blob of a "testing" branch, instead of doing new features and bugfixes all in separate branches..

TBH, its a mess of a repo. That is why more people don't contribute to it - duplicated effort, hard track changes, terrible docs about the changes made, awful cryptic commit messages... No documentation attached to PRs... No reason given when PRs are closed not merged... etc.. etc..

Almost impossible for a new user to get involved..

The reason Alpine and others have gone from zero to hero so quickly is simply cos they have good dev practices - which encourage (rather than discourage) new & skillful devs to want to contribute and get involved.. Alpine, SLAX and others make/made it very easy for devs to get involved, Puppy doesn't.

....And as I have pointed out before, one we have a "good build" setup, which produces a very good puppy, that should be saved out into a separate, versioned branch...

Then ppl can simply do:

git pull
git checkout <some-known-puppy-version-or-build>


Example:

git checkout puppy-precise-5.5

or

git checkout puppy-precise-5.5-lxde


And then they are all setup to produce a specific puppy version/setup, and juts run 0setup etc as nomal...

[sc0ttman]

And BTW, I've read that Puppy is not really a "serious" OS, and no good for coders... etc...

Well, as for Puppy being no good as a developer OS, that is simply not true.

When I first used Puppy in 2009, I couldn't code at all...

I EXCLUSIVELY used puppy to learn to code, and made almost all my stuff on Puppy.. Puppy is one of the best OSes to learn to code, cos it gives so much freedom, runs so fast, and is (usually) so quick and easy to get going..

In fact, using ONLY Puppy, I improved my coding enough to get myself a job in BBC News.. My first job with computers of any kind...

The stuff we make is seen by like 12 million people... I test a lot of it out in Puppy.. (though we use Macs at work)..

Of all the things I've made, only my uni project had to be away from Puppy - again, cos of the silly choice of compiling cut-down system libraries, which break repo packages... I struggled endlessly to make vbox work with Vagrant, so had to ditch puppy for Ubuntu ... But that needn't be the case..

The only other time I HAD to ditch puppy was to make an Android game, cos Android Studio wouldn't work in puppy for me... Again - cut down puppy-specific packages were breaking things ... tight uni deadlines... so was actually quicker to wipe a HD, then install and run ubuntu..

So overall, where we DON'T break repo packages just to save a few MBs, puppy tends to works GREAT as a dev tool ...

Just FYI...

[ozsouth]

Although Peebee's ScPup is my favourite, I like his LxPups, but they don't seem to have the take-up of ubuntu derivatives. LXDE is developed by a team, whereas despite his great efforts, Joe Wing seems to work alone on JWM. Is LubuntuPup possible? Sounds like a combo that may be 'marketable'.

[peebee]

Although Peebee's ScPup is my favourite, I like his LxPups, but they don't seem to have the take-up of ubuntu derivatives. LXDE is developed by a team, whereas despite his great efforts, Joe Wing seems to work alone on JWM. Is LubuntuPup possible? Sounds like a combo that may be 'marketable'.

Thanks!
LxPupBionic............???

[sc0ttman]

peebees LXDE desktop setup should always be one of the offerings in official releases... along with other "flavours"

[Mike Walsh]

@ sc0ttman:-

Scotty, if you work for Auntie, perhaps you can tell us what the plan is for iPlayer when Flash expires next year?

The Beeb are being very tight-lipped about it, but it wouldn't surprise me if they move to a WideVine requirement, necessitated by a DRM subscription model along the lines of NetFlix.....especially since they've now got to support the pensioner's free TV licence out of their own pocket.

That's my thought, anyway. (Sorry to de-rail you..!) Or aren't lowly coders made privy to that kinda stuff..?


Mike.

[sc0ttman]

@ sc0ttman:-

Scotty, if you work for Auntie, perhaps you can tell us what the plan is for iPlayer when Flash expires next year?

Well, i'm in a "news" team, not an iPlayer team... Currently in the elections team, building the results pages for the (possibly) upcoming elections..

But we do know that the BBC is moving towards subscription services, or it will die.

The BBC uses a in-house media player called "SMP", which I've worked on a few years back.. It already support Flash, HTML5 and DRM video.

But I haven't worked on any iPlayer stuff for a few years, so can't say where they're at right now...

But iPlayer will be likely end up DRM, and will require a TV license.

Essentially, iPlayer will become a lot more like Netflix - less a "catch up" service, more a full blown online TV catalogue of everything BBC offers - including more live events, local TV etc..

It's part of BBC being able to put their stuff onto other subscription services too, and reducing the costs of maintaining iPlayer, while simultaneously drastically increasing the amount of content on it..

https://www.bbc.co.uk/mediacentre/speec ... re-iplayer

[mavrothal]

@sc0ttman (and sorry for the personal addressing)
It looks like you know what you want to do and how to do it.
Fork woof-CE, mod it to your liking and push it back or call devs over your fork.
Expecting for someone else to act on instructions may not work very well.
As happened before, if you get the ball rolling in a direction some like they'll come to help.
But YOU have to get the ball rolling.

[s243a]

@sc0ttman (and sorry for the personal addressing)
It looks like you know what you want to do and how to do it.
Fork woof-CE, mod it to your liking and push it back or call devs over your fork.
Expecting for someone else to act on instructions may not work very well.
As happened before, if you get the ball rolling in a direction some like they'll come to help.
But YOU have to get the ball rolling.

Rather than fork Woof-CE the easiest starting place would be to fork one of the puppy specific packages that is bundled in with woof-CE. One could do this if they were interested in modifying one of these packages.

As for https in the forum, a person can't fix this by forking the form, or maybe they can but we'll require some guidance here.

[bigpup]

Just because you can change software code is not a good reason to change it.

What is the specific problem?
Why does it need to be fixed?
Does the fix make the code better?
Does the fix break something else in the code?
Is the code being changed, just because you want it to work this way?

The people that are still around that developed some of the core Puppy programs, still work on them.
Some get tweaked to add a feature or cleanup the code.
But if the program does what it is designed to do.
The bugs are basically all fixed.
Get off the idea that there needs to be a newer version.

[bigpup]

The biggest issue I see is the Puppy Universal Installer needs updating to support UEFI bios computers.
Time for Puppy to come with a install-able boot loader that can be installed to support booting from UEFI.
What is the specific problem?
No install-able UEFI boot loader.
Why does it need to be fixed?
More and more people have UEFI computers.
Does the fix make the code better?
Yes.
It makes it usable on more modern computers.

Grub4dos boot loader is not good enough anymore.
It has no support for UEFI.
No one seems to still be managing Grub4dos program.
What is the specific problem?
It will not boot a normal setup UEFI bios.
Why does it need to be fixed?
People want to be able to boot with normal UEFI bios settings.
Does the fix make the code better?
Yes.

If these programs cannot be coded to fix this issue.
Stop using them in Puppy.
Get some other program to do what they do.

I wonder how many people stop trying to use Puppy just because they can not easily install it.
Universal Installer should do what it says in the name.

[dancytron]

The biggest issue I see is the Puppy Universal Installer needs updating to support UEFI bios computers.

/snipped

Universal Installer should do what it says in the name.

This is the biggest issue holding Puppy back that I'm aware of.

You aren't going to get more users when 80% of people can't install Puppy without turning off security settings in their bios.

If dealing with the old code is a problem, then just rename it "Legacy Univeral installer for pre-UEFI computers" and make a new one from scratch that cribs off of something another distro has done.

[sc0ttman]

@sc0ttman (and sorry for the personal addressing)

That's fine

Expecting for someone else to act on instructions may not work very well...... YOU have to get the ball rolling.

Err... I have done already...

I made a CLI package manager for Puppy (over 7,000 lines of code), just cos Puppy didn't have one...

And it FINALLY enables people to easily:

- create their own repos
- install 3rd party, puppy user created repos
- install 3rd party PPA and slackware repos
- ^ these 3 remove the dependency on the forum somewhat, and paves the way for lots of new puppy sites and repos
- supports SFS as native packages
- easily combine packages and deps into an SFS automatically
- have repos of build scripts only
- "provision" (automated remastering) a puppy programatically (with vagrant, a chroot script, etc)
- use all package manager features, without X (finally)
- it has THREE separate frontends (GTK, ncurses, CLI)
- and much more

^ Literally NONE of that was possible before Pkg without coding it all yourself.

Pkg is feature comparable to apt-get, apk, etc.. I don't know of any other shell based package manager which is half as powerful as Pkg..

It FINALLY opens the door for a no X puppy, with addon SFS to get X - if ppl wanna build that (wouldn't even be possible without Pkg)

But until Pkg is adopted in Puppy proper, we can't advertise Puppy for free in other projects, in the form of CLI installation commands.... Or I would have done that already too!

---

I also said we need better docs... I didn't sit back and moan... I went away and I made mdsh

It is very similar to Jekyll, but with MORE features out of the box.. no easy feat - I even implemented nearly ALL known Liquid filters in shell script for god sake! ..Once I implement the octopod filters, then it will basically be ALL of them.

If mdsh were to be included in Puppy as a default package, users would have a VERY powerful and flexible site/blog/documentation generator for free, out of the box.

I could easily have used Jekyll or Gatsby or an existing site generator, but they didn't work out of the box in Puppy, and couldn't generate Puppy docs as well as a custom solution... so I built one in Puppy, for Puppy... you're welcome

---

Back in the day I also made Woofy - which bridged the gap between Woof (which most users didnt want to use) and the remaster tool, which could only remaster the pup being run...

Woofy opened the door to remasting ANY pup (inc pups which didnt run on the users system), with no skill, and led to peebee starting his LXDE pups that way

----

If I don't say so myself, given that I commute 2.5 hours a day BOTH ways (total 5 hours travel every day), on top of a 9 to 5, I think I am more than pulling my weight to help move Puppy forward.

~EDIT: to be clear, I don't claim any these things are great pieces of work, or better than X, Y or Z, but hopefully ppl can see if I see a "gap" I at least try to fill it if I can, not just ask others to do it..

[s243a]

If I don't say so myself, given that I commute 2.5 hours a day BOTH ways (total 5 hours travel every day), on top of a 9 to 5, I think I am more than pulling my weight to help move Puppy forward.

No argument here! Tank you for your contributions

[s243a]

The biggest issue I see is the Puppy Universal Installer needs updating to support UEFI bios computers.

/snipped

Universal Installer should do what it says in the name.

This is the biggest issue holding Puppy back that I'm aware of.

You aren't going to get more users when 80% of people can't install Puppy without turning off security settings in their bios.

If dealing with the old code is a problem, then just rename it "Legacy Univeral installer for pre-UEFI computers" and make a new one from scratch that cribs off of something another distro has done.

So following scotmann's suggestion, perhaps this is the first thing we should seperate out from woof-CE and fork into its own repo. I believe that there have been some UEFI tools creted for puppy. Perhaps the solution is as simple as adding another menu option in the universal installer which simply calls one of these UEFI tools that someone already built.

[mavrothal]

If I don't say so myself, given that I commute 2.5 hours a day BOTH ways (total 5 hours travel every day), on top of a 9 to 5, I think I am more than pulling my weight to help move Puppy forward.

I can certainly understand that. But I think this is the case with many (all?) other persons trying to contribute to puppy.
All I point out is that all these years I do not see potential developers follow forum wishes or suggestions.

Woof is a pretty complex unorthodoxically designed integrated userland/build system and changes can be messy.
Also there are not may developers that like documentation and people willing to write documentation/translation etc do not like git or poodle or other collaborative environments
Finally web designers the think they hate most, is maintenance.
Thus, the suggestion that the most effective way for something to be done is to just do it!

[sc0ttman]

All I point out is that all these years I do not see potential developers follow forum wishes or suggestions.

Thus, the suggestion that the most effective way for something to be done is to just do it!

Fair enough, I don't disagree with that, but thought I'd share my ideas at least. It can only help kickstart something.


Anyway ..

So out of all this, maybe a good place to start would be to come up with a "definition of done" we can all agree on for any future official releases:

1. Can be installed on x86 UEFI machines (must include UEFI compatible boot loader)
2. Can be installed on x86 BIOS machines
3. Boots to X, using correct/expected video driver
4. Has working ethernet for all included drivers/firmware
5. Has working wifi for all included drivers/firmware
6. Working Bluetooth
7. SAMBA (can connect to Window Share)
8. CUPS is working for all supported printers
9. Packages from the compat distro repos work: VLC, Kodi, OpenShot, (or whatever)
11. Sound works on known supported cards
12. etc

^ that is not a real list (obviously), just an example

It would be a target, or guide, not a hard rule of course (who'd want to "enforce" it?!)..

It would help builders and testers to know what to test, what to tick off..

Users much more knowledgable/thorough than myself, like Marv, BillToo (and many others) could probably help make a proper list - they already have their own testing regimes..

But the point is, a "definition of done" a good way for devs to know what to aim for, testers to know what to test, and for users to know what to expect.

So maybe we can collaboratively come up with a simple, minimal, sensible list of things we expect from a major/official puppy release....?

Or not lol .. don't wanna be a nag

[s243a]

All I point out is that all these years I do not see potential developers follow forum wishes or suggestions.

Thus, the suggestion that the most effective way for something to be done is to just do it!

Fair enough, I don't disagree with that, but thought I'd share my ideas at least. It can only help kickstart something.


Anyway ..

So out of all this, maybe a good place to start would be to come up with a "definition of done" we can all agree on for any future official releases:

1. Can be installed on x86 UEFI machines (must include UEFI compatible boot loader)
2. Can be installed on x86 BIOS machines
3. Boots to X, using correct/expected video driver
4. Has working ethernet for all included drivers/firmware
5. Has working wifi for all included drivers/firmware
6. Working Bluetooth
7. SAMBA (can connect to Window Share)
8. CUPS is working for all supported printers
9. Packages from the compat distro repos work: VLC, Kodi, OpenShot, (or whatever)
11. Sound works on known supported cards
12. etc

^ that is not a real list (obviously), just an example

It would be a target, or guide, not a hard rule of course (who'd want to "enforce" it?!)..

It would help builders and testers to know what to test, what to tick off..

Users much more knowledgable/thorough than myself, like Marv, BillToo (and many others) could probably help make a proper list - they already have their own testing regimes..

But the point is, a "definition of done" a good way for devs to know what to aim for, testers to know what to test, and for users to know what to expect.

So maybe we can collaboratively come up with a simple, minimal, sensible list of things we expect from a major/official puppy release....?

Or not lol .. don't wanna be a nag

A check list seems to be an easy thing to do and no one is forced to use it (or even check off every item) so I way why not? Maybe we can call your above list rev_0.0.0.0

[sc0ttman]

Up to everyone else I spose...

But it makes me think another way to get more people into (and contributing to) Puppy from "outside" would be a Developers Handbook.

Just a Puppy focused Handbook, forming part of a simple website, like the one I described elsewhere, but for developers and designers.

It could cover:

- Puppy concepts
- Puppy architecture and design
- Useful links, programs, etc
- About Woof-CE
- About important puppy scripts (how they work, etc)

- How to contribute:
--- How to compile the kernel
--- How to compile programs
--- How to make GtkDialog programs
--- How to make Vala programs
--- Sharing your work
- Common code examples (i18n, gettext, etc)
- etc

We have this forum, existing docs, Barrys blogs, and various other places from which to steal this info.

Most users wouldn't care to read it, but it could be a useful help to curious coders who want to tinker and help out.

[sc0ttman]

And of course anyone elses suggestions about "Getting more users to use puppy" are as welcome/valid as mine, to be clear .. this thread wasn't mean to be a soapbox.. I just see some easy wins (IMHO)..