Community Edition anyone interested?

News, happenings
Message
Author
User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#511 Post by pemasu »

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.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#512 Post by musher0 »

@ amigo

Good & practical article, that.

BFN.

musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#513 Post by jpeps »

musher0 wrote:@ amigo

Good & practical article, that.

BFN.

musher0
Here's another:

Step 2:
"Came to believe that a Power greater than ourselves could restore us to sanity"

darry1966

#514 Post by darry1966 »

jpeps wrote:
musher0 wrote:@ amigo

Good & practical article, that.

BFN.

musher0
Here's another:

Step 2:
"Came to believe that a Power greater than ourselves could restore us to sanity"
nicely said

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#515 Post by musher0 »

darry1966 wrote:
jpeps wrote:
musher0 wrote:@ amigo

Good & practical article, that.

BFN.

musher0
Here's another:

Step 2:
"Came to believe that a Power greater than ourselves could restore us to sanity"
nicely said
Hi, guys.

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)

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#516 Post by jpeps »

musher0 wrote:

But how are they relevant to a community PuppyLinux distro? I don't follow.
Please explain.

Thanks in advance. BFN.

musher0
It's about clear vision. If it seems overly complex and difficult/impossible to maintain..it probably is.

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/

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#517 Post by musher0 »

@ 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
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

darry1966

#518 Post by darry1966 »

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.

gcmartin

#519 Post by gcmartin »

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.

User avatar
L18L
Posts: 3479
Joined: Sat 19 Jun 2010, 18:56
Location: www.eussenheim.de/

#520 Post by L18L »

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....
Yes please, start building something for modern computers.
When you will have finished it, this computer will also be an old one. :wink:

darry1966

#521 Post by darry1966 »

L18L wrote:
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....
Yes please, start building something for modern computers.
When you will have finished it, this computer will also be an old one. :wink:
Exactly the progress being made is very slow hence my fustration and Jpeps, lots of eloquent speeches which mean well.

Confusion over direction etc especially Retro computers as well and what the bases for development will be.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#522 Post by jpeps »

L18L wrote:
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....
Yes please, start building something for modern computers.
When you will have finished it, this computer will also be an old one. :wink:
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.

MS and Apple are competing with the shareware model by giving away software. Prices should continue to come down.

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

Modularity -- another approach

#523 Post by mikeslr »

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
Last edited by mikeslr on Tue 10 Dec 2013, 21:23, edited 2 times in total.

slenkar
Posts: 228
Joined: Sat 11 Jul 2009, 01:26

#524 Post by slenkar »

I agree with mikeslr

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

Mix and Match may have to be re-thought

#525 Post by mikeslr »

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

darry1966

#526 Post by darry1966 »

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.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#527 Post by technosaurus »

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].

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#528 Post by jpeps »

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
Minor hoops like it won't compile?

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#529 Post by technosaurus »

jpeps wrote:
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
Minor hoops like it won't compile?
... _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.
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].

gcmartin

#530 Post by gcmartin »

This post tries to understand a prior quote:
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 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.

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?

Post Reply