Puppy Linux Discussion Forum

[Lobster]

Saluki is the fastest dog in the world over long distances

Saluki wiki page
http://puppylinux.org/wikka/Puppy6

Back to basics
Puppy compiled in Puppy
'Puppy from Scratch'
Smaller iso
Recompiled packages

Puppy Base layout
Every Puplet and wooflet uses slightly different layout of menus
for consistency we will try to establish a 'standard'
Control center
There are several control centers - in dpup, Dude etc
Quickpet
is a huge success and can be added to
Browser choice, window manager choice, Dude etc
Xcowsay messaging
Well not essential but fun


Early discussion in this thread and also

Puppy from Scratch
http://www.murga-linux.com/puppy/viewtopic.php?p=434275#434275

5.1 to 6
http://www.murga-linux.com/puppy/viewtopic.php?t=55028

[Aitch]

Lobster

I nominate Joe/big_bass's TXZ_pup 4.5 as a possible source of ideas, too, as the basis of a puppy from scratch needs easy add/remove files, and dependency checking/updating capability.....surely?

Is this going to be another Community effort?

see also

http://murga-linux.com/puppy/viewtopic.php?t=59429

http://murga-linux.com/puppy/viewtopic.php?t=59408

Are we going to just churn out another kernel updated version, or go radical?

My hope is that we can address some of the newer technology trends we see coming, lest we get left behind.....

PS: Techno, what happened to 4.4/Woofy?

Aitch

[Lobster]

[paulhomebus]

[Aitch]

I forgot to link this request for network boot

http://www.murga-linux.com/puppy/viewtopic.php?p=58997

Aitch

[ragaman]

Lobster mentioned window manager choice. How about including LXDE with pre-made skins (like what someone did with ChameleonOS). I spend at least 12 hours a day working on my PC. It helps if it looks good.

Just my humble opinion.

[ttuuxxx]

I would like to see Wary puppy take puppy 6 as the default and Quirky as a alternative for new pc's.
The reason is that Wary is getting a lot of attention and its around 118MB, Unlike puppy 5 at 130MB.
I personally like puppy standing on its on feet and not depending on other distros like ubuntu or slackware.
Wary is based on T2 like 4 series.
ttuuxxx

[big_bass]

the next logical step for me is compile all the packages and update everything

now that I have a simple independent build system

that doesnt depend on slackware binaries it just uses the slackware package format to build with this allows you to recompile and update easily


that isnt a weekend project
if anyone really wanted to just do it and not wait around speculating what will be ...
things will always change and leave you
in the dark

so if you really wanted to go for it
you would have to take the risk
and be independent of the latest (that just shows you cant do it )
and that means make your own a piece at a time
and that could cost you "temporary official status "

but if you cant make some of the pieces needed how can you make and maintain the whole ?
whatever the whole distro would be

points to ponder

do you want the man to be" kind " and help ?


BUTTERFLY

A man found a cocoon of a butterfly. One day a small opening appeared. He sat and watched the butterfly for several hours as it struggled to force its body through that little hole. Then it seemed to stop making any progress. It appeared as if it had gotten as far as it could, and it could go no further.

So the man decided to help the butterfly. He took a pair of scissors and snipped off the remaining bit of the cocoon.

The butterfly then emerged easily. But it had a swollen body and small, shriveled wings.

The man continued to watch the butterfly because he expected that, at any moment, the wings would enlarge and expand to be able to support the body, which would contract in time.

Neither happened! In fact, the butterfly spent the rest of its life crawling around with a swollen body and shriveled wings. It never was able to fly.

What the man, in his kindness and haste, did not understand was that the restricting cocoon and the struggle required for the butterfly to get through the tiny opening was nature's way of forcing fluid from the body of the butterfly into its wings so that it would be ready for flight once it achieved its freedom from the cocoon.



Joe

[scsijon]

Read this once and decided to have a think!

Response is as follows!

What I'd like to see is a decent versioning of the releases, and using Barry's "bones" and "woof", I believe we could. This is the time to set that up!

To expand the thought (I hope it's understandable):

---------------------------------------------------------------------------------
First Release has the path name of Puppy 6.0

Alpha releases with Major version code of 000
Alpha has minor Version codes of 01 to 49 (00 reserved)
This gives you an alpha set of 6.0.01 to 6.0.49 (surely this would be enough and normally not all would be used). Anything can happen at this stage in the build (from package reform to linux core version change). Every individual package is checked and updated by someone. A controlled set of testers used at this stage ("package or hardware specialists") to deal with the initial bugs and clashes.

Beta Releases with Major version code of 000
Beta Releases have Minor version codes of 50 to 89
This gives you a beta release testset of 6.0.50 to 6.0.89 (ditto comment to alpha). Here you should have your linux core "set" (you may even be building for three or four as q070 has), you have a "rough list" of applications up and running (maybe still a fault or two being fixed) and have a "pretty good idea" on what the release will look like. An open set of testers would be used, allowing for multiple "boxes, notebooks, and equipment. Testers must have submitted their hardware (lspci, etc) to be an "authorised tester", but this doesn't mean anyone can't download and run it. It just means that a decent range of gear is used, as it's not worth having ten dell 8000's doing the same set of tests but three or four with different attached hardware would be worthwhile.

RC releases with Major version code of 000
RC has minor version codes of 90-98
This gives you nine Release Candidate Versions, if needed. 6.0.90 to 6.0.98.
NO new packages/updates allowed, final platform bugfixes only.
(If you need more you went to RC early or have came across a bug that says you should step back to either an alpha or beta version codes and start again from there! Anyone could test and any showstoppers should have appeared before this, but.....)

The "Final Release" automatically gains the 6.0.99 code and would be known as the "Puppy 6.0 release".

Next Puppy 6.1 release version would use 6.1.01 to 6.1.99, and so on.

Remember that woof allows three digit Major version numbers, so there is no reason why we couldn't have a 6.999 release.

This could also allow others to have their own 6.xxx version of their own pups as long as they have applied and been issued with a Major version number.
It would also allow Mentoring by those that have built with those who are just starting or building a "slightly complicated pup".
That should widen our horizons, not just in the "english" speaking world, but in those many other languages that exist on our planet.
-------------------------------------------

well that's my idea anyway, we need to start to standardize our release coding. Sorry folks, but it just seems to be getting messy (as it's got in 5.1 and 5.1.1.), only the "developets" knew what was up.

what's others thoughts on fixing this problem?

regards
scsijon
ps (and the 6.0.00 code would be the initial package list for the developers to argue over. )

[Iguleder]

I think we should go for a T2 build. All packages built with T2 and frozen. All the latest packages plus a choice of 4-5 kernels (2.6.18, 2.6.25.16, 2.6.27.47, 2.6.30.5 and the latest, with SMP). If a package is found to be problematic, we can upgrade/downgrade/recompile it manually as Barry did with Wary and Quirky.

All 6.x releases should use the same packages, except updates to in-house stuff like Pmusic, multimedia stuff and end-user applications. The 4.x and Quirky way of doing things proved to be the most reliable method for creating puppies. It also ensures compatibility and stability.

Additionally, having our own packages lets us choose our release cycle without taking other release cycles into consideration (i.e the Ubuntu release cycle) and gives us more control over dependencies, which results in smaller size.

I'm totally against making some distro based on legacy stuff just for old computers, that's one of Puppy's main goals but definitely not the most important one.

I say no to uClibc, Flash 7/8/9, old glibc, old libraries, ancient applications and Qt stuff. I'd like Puppy to have things like dbus, a notification daemon, proper volume management, a proper network manager, a bluetooth manager, better laptop support and modern technologies found in all major distros. Also, I'd like all gtkdialog stuff to be rewritten in plain C and gradually make Puppy depend less and less on gtkdialog and Bash 3.x, until both can be dropped completely.

2c

EDIT: I'd like to use the 4.x/dpup version numbers. For instance, development starts at 550, let's say we have 10 alpha releases ... we reach 560. Then comes out the beta, we bump it to 570. Another testing cycle, let's say 7 releases ... 577. The RC is 590, another 3 release candidates and we bump it to 600. Nothing fancy and no Microsoft-like version numbers or codenames.

[jemimah]

Really, these threads where everyone just states their opinions, only serve to illustrate why it's so difficult to build teams. The fact is, no two people have exactly the same vision. If you want something done right, you have to do it yourself. Teamwork is compromise.

IMO, there is only one important question on the table here. Are there multiple people with the skill, spare time, and communication skills who want to work together to build something great from the ground up.

If not, that's fine. Puppy will continue the way it always has.

Arguing what color to paint the bike shed is a pointless waste of time.
http://en.wikipedia.org/wiki/Bike_shed

[Lobster]

I am using a version of Wary with a boot menu option (already)

[scsijon]

After further thought and reading others comments, I'll add two notes to what i've written before:

1/ T2, at least for the core. We should be independant of other linux flavours otherwise we will end up being listed as a "copy". It doesn't mean we shouldn't be able to use their apps packages though. I'd like to see a complete set of conversion packages available as part of a puppy-xxx-dev.sts, with the usual caveats of course.

2/ (extracted from what I origonally added to 5.2 wiki, but maybe of more use here). I won't add it to the Puppy6 wiki unless asked.

"handled as multiple sts files
- a basic puppy-xxx.sts with no user type apps only system and core basics;
- has a primary :userapps.sts" that loads automatically if it's there;
- other sts's loaded with bootmanager as usual or installed if a full install.

> it would allow both existing and new puppy derivitive developers to work with a solid and standard base, by adding their own "flavoured" userapps.sts file and keeping up (within reason) with the flow without the problems of a full build.

my idea anyway
scsijon "

I'll expand on my ideas/thoughts further if anyone wants to ask actual questions.

Oh, and Lobster, I'd like to wait a month or two (max3), barryk has just put wary 070 out and is talking about a full release soon; pd&micko have nearly finished 5.1.1 and working on 5.1.2/5.2 already; t...x is into something else i believe at present and he still has at least 4.3.2 awaiting a promised completion; and most others seem to be or are already into projects, Your the only leader/mentor visable at present. I don't mind helping, but I'm not diving into the deep end!

regards
scsijon
I giove up, TYPO'S RULE!

[Lobster]

[big_bass]

jemimah