Saluki, Puppy Remastered
- Lobster
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
Saluki, Puppy Remastered
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/viewto ... 275#434275
5.1 to 6
http://www.murga-linux.com/puppy/viewtopic.php?t=55028
Last edited by Lobster on Thu 07 Oct 2010, 11:12, edited 7 times in total.
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
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
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
Well I would be happy to second that.I nominate Joe/big_bass's TXZ_pup 4.5
I would be more than happy to have Joe as project leader.
Jemimah too would be someone who could unite a core team.
It is up to them. It is paced and gradual work with others contributing compiled programs.
And the rest of us testing and providing feedback.
Some things worked very well in 5.1.
Release very often. Allow space. Larry allowed Mick to provide Quickpet, compiled programs and language support and Warren to develop the look and feel.
I hope they will continue contributing to both 5.2 and this new initiative which we have talked about and now can begin to implement.
Last edited by Lobster on Sun 19 Sep 2010, 04:13, edited 1 time in total.
- paulhomebus
- Posts: 120
- Joined: Thu 21 Jan 2010, 23:23
- Location: New Zealand
- Contact:
I forgot to link this request for network boot
http://www.murga-linux.com/puppy/viewtopic.php?p=58997
Aitch
http://www.murga-linux.com/puppy/viewtopic.php?p=58997
Aitch
- ttuuxxx
- Posts: 11171
- Joined: Sat 05 May 2007, 10:00
- Location: Ontario Canada,Sydney Australia
- Contact:
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
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
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)
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
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
puppy6 "versioning"
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. )
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
- Posts: 2026
- Joined: Tue 11 Aug 2009, 09:36
- Location: Israel, somewhere in the beautiful desert
- Contact:
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.
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.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
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
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
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!
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
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
Over to the risk takers then . . .so if you really wanted to go for it
you would have to take the risk
Wary is based on T2 like 4 series.
You have to compile (bootstrap) in something
Once again, the unique perspective
shared by at least 3 developers
is that of compiling from scratch
This basis as a 'sounding board'
can easily evolve and change
http://puppylinux.org/wikka/Puppy6
Maybe the bootstrap is the fist step and that does not exist yet.
That makes sense
Thanks guys.
Puppy
Organic
jemimah
I want a raw version
a clean white page with people not worried about if its official or not
thats a big mental obstacle and forces you into limited thinking
we need something raw from those that use linux everyday
raw ... very raw like an artist asked to do a job
without restricting the creativity
everyone adds the best they have to offer
Joe
yeahIMO, 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.
I want a raw version
a clean white page with people not worried about if its official or not
thats a big mental obstacle and forces you into limited thinking
we need something raw from those that use linux everyday
raw ... very raw like an artist asked to do a job
without restricting the creativity
everyone adds the best they have to offer
Joe
- Lobster
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
You are talking SushiI want a raw version
(I like it already)
Joe I know you and Jemimah have been chatting
I can not get into the developer chat room
any more (just as well)
I am quite happy to use your pre woof Slackware base
and modify the wiki page as it emerges
Are Jemimah and Ttuuxxx along for the ride too?
Ttuuxxx is invaluable and Jemimah has a proven track record
with Puppeee and Fluppy.
What I am trying to establish is an initiative from the developer pool
that says we are gonna try and create Puppy 6
everyone adds the best they have to offer
Butterflys + fish = flying fish
If that is your sort of fish supper
I will bring the chips
Puppys are penguins
Fish for breakfast!
The developer chatroom I think is kinda dead. I've been hanging out on IRC as time permits. It's more fun there.
Barry would have to approve anything called Puppy 6. I'm with big_bass - I don't much care if the status is "official".
I don't have enough ambition to start something on my own from scratch. But I will contribute to interesting projects if asked.
Barry would have to approve anything called Puppy 6. I'm with big_bass - I don't much care if the status is "official".
I don't have enough ambition to start something on my own from scratch. But I will contribute to interesting projects if asked.
- ttuuxxx
- Posts: 11171
- Joined: Sat 05 May 2007, 10:00
- Location: Ontario Canada,Sydney Australia
- Contact:
Well Lobster I'm here as long as distro size matters, Really my home pc's can run the latest full size distros, but puppy is suppose to be small, for people who need resources. Like I mentioned before it has grown almost 50% between puppy 4.0 and 5.0, I won't support that! Plus that's with a higher sfs compression ratio. If someone wants to build a base, I'm willing to compile 100+ apps like I did for 2.14X and 4.2. Either Wary or from scratch is fine with me, but we need to stick to the grass roots, Mplayer on wary I've found not to be stable, Pmusic wouldn't play mp3's either, maybe its a alsa/oss issue. I like the idea of a older mature kernel and Xorg, with the latest gtk2,glibc.Lobster wrote:I want a raw version
Are Jemimah and Ttuuxxx along for the ride too?
Ttuuxxx is invaluable and Jemimah has a proven track record
with Puppeee and Fluppy.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)
Hi all
I know that I am a newbie, but enjoyed testing the Lucid puppies with 01micko, Playdayz and the team (and learnt a lot from it) , and would be willing to help test (try to break) any new puppies.
It is hard to get people to agree on the next step forward, but look forward to puppy 6 (When it is agreed what it should be)
Cheers
Stripe
I know that I am a newbie, but enjoyed testing the Lucid puppies with 01micko, Playdayz and the team (and learnt a lot from it) , and would be willing to help test (try to break) any new puppies.
It is hard to get people to agree on the next step forward, but look forward to puppy 6 (When it is agreed what it should be)
Cheers
Stripe