Community Edition anyone interested?
yes|linux-header|linux-libc-dev|exe>dev,dev,doc,nls >>> from distro repo
yes|linux_headers||exe>dev,dev,doc,nls >>> kernel kit creates this, plus compiles the kernel semi-automatically; meaning dowloads kernel tarball, latest aufs, extracts them, patches kernel source with aufs and other patches, asks if you want to use ready DOTconfig from selection and launches menuconfig or other gui, compiles - installs the creation to the folders - creates the folders for woof compliant kernel pet and that linux_headers folder, creates the kernel source sfs, which has been cleaned and made ready for compiling drivers.
Dir2pet > throw them to packages-pet , update package database file and woof a distro.
Done.
yes|linux_headers||exe>dev,dev,doc,nls >>> kernel kit creates this, plus compiles the kernel semi-automatically; meaning dowloads kernel tarball, latest aufs, extracts them, patches kernel source with aufs and other patches, asks if you want to use ready DOTconfig from selection and launches menuconfig or other gui, compiles - installs the creation to the folders - creates the folders for woof compliant kernel pet and that linux_headers folder, creates the kernel source sfs, which has been cleaned and made ready for compiling drivers.
Dir2pet > throw them to packages-pet , update package database file and woof a distro.
Done.
Hi, guys.darry1966 wrote:nicely saidjpeps wrote:Here's another:musher0 wrote:@ amigo
Good & practical article, that.
BFN.
musher0
Step 2:
"Came to believe that a Power greater than ourselves could restore us to sanity"
Great words of wisdom, from a great international and multi-faceted movement...
But how are they relevant to a community PuppyLinux distro? I don't follow.
Please explain.
Thanks in advance. BFN.
musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
It's about clear vision. If it seems overly complex and difficult/impossible to maintain..it probably is.musher0 wrote:
But how are they relevant to a community PuppyLinux distro? I don't follow.
Please explain.
Thanks in advance. BFN.
musher0
Frankly, I don't know if that's possible from a "community"
"In March, Andy Rubin, one of Android’s co-founders and the man who led it to world dominance, announced he was stepping back from his role spearheading the mobile OS. His replacement: Google’s Chrome OS head Sundar Pichai"
http://venturebeat.com/2013/05/13/googl ... s-silence/
Incidentally, the vision also has to be in synch with current needs, or it doesn't go anywhere.
"In 2004, Sony excited tech enthusiasts with a 1 terabyte home server that cost $5,000. Now, notebook drives can support a terabyte".
http://gigaom.com/2013/12/08/why-digita ... t-in-tech/
@ jpeps
Thanks for the explanation.
True. A vision too wide chokes on itself... has too much input to swallow. Instead of a
community distro, then, maybe a PuppyLinux "des refusés" (of the refused, literally;
clone of an expression serious graphic artists will be familiar with). In time, these
"refused" artists became the ones we remember.
Another approach: an "off-off-Broadway" Puppy, comprised of only little-known
scripts and programs, great but neglected in the "official" Puppies.
Still another direction could be "trendy Puppy". Numerous possible "trends" here,
a little subjective, though.
What I mean is: importance of focus and structure; there has to be some.
To do a certain task or fulfill a certain need, a community usually lists what it wants
done, and then delegates a committee of people with know-how. In turn, these
people bring the project to completion, respecting AMAP (as much as possible)
the input of the community.
Just thinking out loud. Oh well... BFN.
musher0
Thanks for the explanation.
True. A vision too wide chokes on itself... has too much input to swallow. Instead of a
community distro, then, maybe a PuppyLinux "des refusés" (of the refused, literally;
clone of an expression serious graphic artists will be familiar with). In time, these
"refused" artists became the ones we remember.
Another approach: an "off-off-Broadway" Puppy, comprised of only little-known
scripts and programs, great but neglected in the "official" Puppies.
Still another direction could be "trendy Puppy". Numerous possible "trends" here,
a little subjective, though.
What I mean is: importance of focus and structure; there has to be some.
To do a certain task or fulfill a certain need, a community usually lists what it wants
done, and then delegates a committee of people with know-how. In turn, these
people bring the project to completion, respecting AMAP (as much as possible)
the input of the community.
Just thinking out loud. Oh well... BFN.
musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
All I can say as I believe there should be 2 different Pups. I suggested the Retro Puppy Community 4.32 or 4.31 base when it has been decided to use 2.14X which as I have previously said has an inferior Xorg which I might add has missing GLX libraries namely Xorg 7.0 when 4.31/4.32 has the proven Xorg 7.31 which of course can upgrade to Xorg Full.
I also see that 2.14XTop10 has Glibc 2.10 which is clearly an upgrade so I guess simple question is why can the same be done for 4.31/4.32 if it can be done on an earlier Pup - give it the 2.14X treatment?????????????. Glibc 2.10 at the moment seems adequate for a Retro Pup where you won't necessarily being running the latest and greatest but still being able to compile more modern apps would be nice.
As for Jpeps I think is absolutely correct in what he is saying about a modern Pup it should meet with what is required now so as part of the community he is rightly voicing that. He knows a lot more about the modern side of computing than I and I'm sure if you pick his brain he has much useful knowledge to impart.
He and I are concerned about a little lack of direction with this community and wish it to be focused on clear goals the discussion has been going on for along while with only some progress and it is good to see Pemasu onboard - so credit where credit is due.
Also credit for building WoofCE a building block and for Dpup Wheezy
I do believe in the community model but it must follow clear direction and a logical path.
I also see that 2.14XTop10 has Glibc 2.10 which is clearly an upgrade so I guess simple question is why can the same be done for 4.31/4.32 if it can be done on an earlier Pup - give it the 2.14X treatment?????????????. Glibc 2.10 at the moment seems adequate for a Retro Pup where you won't necessarily being running the latest and greatest but still being able to compile more modern apps would be nice.
As for Jpeps I think is absolutely correct in what he is saying about a modern Pup it should meet with what is required now so as part of the community he is rightly voicing that. He knows a lot more about the modern side of computing than I and I'm sure if you pick his brain he has much useful knowledge to impart.
He and I are concerned about a little lack of direction with this community and wish it to be focused on clear goals the discussion has been going on for along while with only some progress and it is good to see Pemasu onboard - so credit where credit is due.
Also credit for building WoofCE a building block and for Dpup Wheezy
I do believe in the community model but it must follow clear direction and a logical path.
Members, here, are looking to participate in a clear "stated" direction. But, we still have people/persons running around with these old attitudes of bloat and minimalist. If we can stop the name calling of things and coalesce around a theme; then, some/many of these members will step up to the task of working together to contribute.
There has been enough ideas thrown out to ID the steps/tasks to move positively.
Here's one that is taken and reworded from some of the comments users have made, but, its worded different than they have expressed. Nonetheless, this is an idea which much of us can identify. The community has been looking at a "Puppy" desktop for quite a while. As such, we have a good idea of the first level of areas found in the taskbar Menu. This is a reasonable CE to strive for as it is so well-known and familiar to everyone. The system and subsystem familiarity would fast-track problem ID and resolutions.
Idea from what is already stated
This suggest that one start for CE, could well be a new PUP which provides the SAME functionality that Puppy, FATDOG, LightHouse64 now provide the community. As such, we define for the experienced among the community a document to guide removal of the things they done want. In fact, the minimalist could be an enormous help in this documented process. The normal/inexperience users would use as is. and the Super-users would add via package management those additional items preferred in their advanced system use. The CE must document this stated direction and the community must pledge itself to rally around the CE to get it out the door. This may just be what's needed to address the 3 groups of users mentioned.
And for heavens sake, let's stop this bad behavior of branding bloat-minimalist and let's recognized the PCs many new users are bringing with them to this community. This affords everyone of us an opportunity to make new friends, AND, CE direction also can help us see a new way of achieving a disto as we "mature" Puppy Linux.
Does the author/members feel we are getting to a point of being able to "move" onto a new channel to begin documenting in preparation for a start?? If so, take a stab at it.
There has been enough ideas thrown out to ID the steps/tasks to move positively.
Here's one that is taken and reworded from some of the comments users have made, but, its worded different than they have expressed. Nonetheless, this is an idea which much of us can identify. The community has been looking at a "Puppy" desktop for quite a while. As such, we have a good idea of the first level of areas found in the taskbar Menu. This is a reasonable CE to strive for as it is so well-known and familiar to everyone. The system and subsystem familiarity would fast-track problem ID and resolutions.
Idea from what is already stated
This suggest that one start for CE, could well be a new PUP which provides the SAME functionality that Puppy, FATDOG, LightHouse64 now provide the community. As such, we define for the experienced among the community a document to guide removal of the things they done want. In fact, the minimalist could be an enormous help in this documented process. The normal/inexperience users would use as is. and the Super-users would add via package management those additional items preferred in their advanced system use. The CE must document this stated direction and the community must pledge itself to rally around the CE to get it out the door. This may just be what's needed to address the 3 groups of users mentioned.
And for heavens sake, let's stop this bad behavior of branding bloat-minimalist and let's recognized the PCs many new users are bringing with them to this community. This affords everyone of us an opportunity to make new friends, AND, CE direction also can help us see a new way of achieving a disto as we "mature" Puppy Linux.
Does the author/members feel we are getting to a point of being able to "move" onto a new channel to begin documenting in preparation for a start?? If so, take a stab at it.
- L18L
- Posts: 3479
- Joined: Sat 19 Jun 2010, 18:56
- Location: www.eussenheim.de/
Yes please, start building something for modern computers.darry1966 wrote:..As for Jpeps I think is absolutely correct in what he is saying about a modern Pup it should meet with what is required now so as part of the community he is rightly voicing that....
When you will have finished it, this computer will also be an old one.
Exactly the progress being made is very slow hence my fustration and Jpeps, lots of eloquent speeches which mean well.L18L wrote:Yes please, start building something for modern computers.darry1966 wrote:..As for Jpeps I think is absolutely correct in what he is saying about a modern Pup it should meet with what is required now so as part of the community he is rightly voicing that....
When you will have finished it, this computer will also be an old one.
Confusion over direction etc especially Retro computers as well and what the bases for development will be.
Frankly, I don't see the point of trying to "puppify" something like an android device that has access to a million apps and is specifically adapted to touch screens. Better tools may become integrated as available. Until then, what's wrong with the current method of just fixing and improving what is already available? Devices are now moving to larger screens with more serious applications, so will become increasingly competitive.L18L wrote:Yes please, start building something for modern computers.darry1966 wrote:..As for Jpeps I think is absolutely correct in what he is saying about a modern Pup it should meet with what is required now so as part of the community he is rightly voicing that....
When you will have finished it, this computer will also be an old one.
MS and Apple are competing with the shareware model by giving away software. Prices should continue to come down.
Modularity -- another approach
Hi All,
Having noticed that each new class of Pups is slower than the last (and I think wireless less capable of picking up weak/distant signals) , I've been reading thru the pUPnGo thread.
If I understand correctly, a big if, the most significant factor which adversely impacts the speed and size of Pups has been the increase in size of glibc and Gtk. Someone, I forget who, recently posted that Pups can use any Gtk version, indeed, several versions. And if I understand amigo's post, glibc is not kernel dependent but can be compiled under any kernel.
Goingnut's method in pUPnGo was to strip a 4.12 pup to a bootable core, but provide user-functionality by placing applications in zdrv which would be loaded at bootup. But he began his work before jemimah developed the adrv. [Jemimah was aware of goingnut's work, and may have been inspired by it]. After that development, Pups could be built to load at initial bootup both an zdrv (which traditionally only contains drivers) and an adrv which contained applications. Thereafter, additional applications could be added by the user via SFS load and/or pet install, (or in Saluki and Carolina using custom-builder to build a new adrv).
So I wonder if, rather than multiple Pups (other than one 32-bit non-pae and one 64-bit), the following would be possible:
(1) a “core
Having noticed that each new class of Pups is slower than the last (and I think wireless less capable of picking up weak/distant signals) , I've been reading thru the pUPnGo thread.
If I understand correctly, a big if, the most significant factor which adversely impacts the speed and size of Pups has been the increase in size of glibc and Gtk. Someone, I forget who, recently posted that Pups can use any Gtk version, indeed, several versions. And if I understand amigo's post, glibc is not kernel dependent but can be compiled under any kernel.
Goingnut's method in pUPnGo was to strip a 4.12 pup to a bootable core, but provide user-functionality by placing applications in zdrv which would be loaded at bootup. But he began his work before jemimah developed the adrv. [Jemimah was aware of goingnut's work, and may have been inspired by it]. After that development, Pups could be built to load at initial bootup both an zdrv (which traditionally only contains drivers) and an adrv which contained applications. Thereafter, additional applications could be added by the user via SFS load and/or pet install, (or in Saluki and Carolina using custom-builder to build a new adrv).
So I wonder if, rather than multiple Pups (other than one 32-bit non-pae and one 64-bit), the following would be possible:
(1) a “core
Last edited by mikeslr on Tue 10 Dec 2013, 21:23, edited 2 times in total.
Mix and Match may have to be re-thought
Hi again,
It was suggested to me via email that "mix and match" could result in a mess. On reflection, my guess is that's probably true regarding glibc. At any rate, it's an unknown, something best tested other than in a Community Edition. On the other hand, we already have pups which use a couple of versions of Gtk. So I'd amend the previous post to provide only for Gtk SFSes for "mixing" with the warning that (a) just adding a higher number gtk may not be sufficient to support applications dependent on a different adrv and (b) SFSes can be unloaded if they generate problems. Users can also be advised that a possible consequence of changing adrv's is that applications installed to a SaveFile (or remaster) may break and application SFSes may not function if they required the glibc of a different adrv.
mikesLr
It was suggested to me via email that "mix and match" could result in a mess. On reflection, my guess is that's probably true regarding glibc. At any rate, it's an unknown, something best tested other than in a Community Edition. On the other hand, we already have pups which use a couple of versions of Gtk. So I'd amend the previous post to provide only for Gtk SFSes for "mixing" with the warning that (a) just adding a higher number gtk may not be sufficient to support applications dependent on a different adrv and (b) SFSes can be unloaded if they generate problems. Users can also be advised that a possible consequence of changing adrv's is that applications installed to a SaveFile (or remaster) may break and application SFSes may not function if they required the glibc of a different adrv.
mikesLr
Sounds like an interesting idea Mikesir however this is a community distro thread and the idea is to produce iso's 1. for retro whatever that is as long as it offers support for more than a few types of retro machines an updated 4.32 a distro that had a wide base of support and video capability that was ideal enough for old kit would be ideal and something to fit with modern needs so lets keep our heads and feet on the ground and not keep this thread going as some kind of wish list that unfortunately it has become as Jpeps was more or less saying between the lines "keep it realistic" - Get a good base for each going and then the testers having something to work with we ain't a concord.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
Just make the devx.sfs have the oldest supported version of glibc, gtk, etc... End of problem. If a developer/packager wants/needs to build against a newer version, then they will have to go through minor hoops he/she should be prompted to mention it - preventing a lot of common issues.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
... _may_ not compile (many/most will) unless you update packages, but if you are going to make newbs update their packages, then you should at least be able to make them aware ... having to update it themselves would make packagers aware that it would not be supported in some versions without updates so they can pass along the info. ... for example abiword would compile with gtk+-2.12 (and worked better in Puppy due to omitted gvfs) but if compiled in gtk+-2.14 or greater it would not work on older versions at all and many functions were broken if used with gtk versions >= 2.14.jpeps wrote:Minor hoops like it won't compile?technosaurus wrote:Just make the devx.sfs have the oldest supported version of glibc, gtk, etc... End of problem. If a developer/packager wants/needs to build against a newer version, then they will have to go through minor hoops
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
This post tries to understand a prior quote:
I find this an interesting comment as most every PUP ships with a utility which shows performance. It is easy to run. And, I am not so sure whether the quote refers to a particular application or the desktop or LAN services when read-write to LAN PCs or web/multimedia serving or ???
I have NOT observed this nor have I seen anything widespread in the community reporting that suggest such.
Lastly, if an application/subsystem has been enhanced is such a way as to increase functionality to the user with little penalty, this couldn't possibly mean that the application is bad.
Puppy runs very very well when matched against other industry Linux distros.
How many of this community have also seen a "degradation" in performance of PUPs?
If so, should the CE start with that as an item for new?
I have NOT noticed this. And, I question how this could be true. Each PUP even those which are based upon other's base, come to us with its own characteristic behavior. Much of that is derived from advance functionality via kernel while other is due to advanced ability in both subsystems and application (which include utilities). Puppy, IIRC, is fast....stable for the most part ... and highly functional and usable.Having noticed that each new class of Pups is slower than the last (and I think wireless less capable of picking up weak/distant signals) , I've been reading thru the pUPnGo thread.
I find this an interesting comment as most every PUP ships with a utility which shows performance. It is easy to run. And, I am not so sure whether the quote refers to a particular application or the desktop or LAN services when read-write to LAN PCs or web/multimedia serving or ???
I have NOT observed this nor have I seen anything widespread in the community reporting that suggest such.
Lastly, if an application/subsystem has been enhanced is such a way as to increase functionality to the user with little penalty, this couldn't possibly mean that the application is bad.
Puppy runs very very well when matched against other industry Linux distros.
How many of this community have also seen a "degradation" in performance of PUPs?
If so, should the CE start with that as an item for new?