Community Edition anyone interested?

News, happenings
Message
Author
User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

Re: Old hardware Base

#501 Post by Iguleder »

darry1966 wrote:214X just doesn't work for me.
The problematic word here is "me". Everybody has their hardware and that old Puppy that works fine for this specific setup.

Just face it! You can't support today's hardware with old software (Wary, 2.14x, any retro Puppy or old Puppy versions) and you can't just upgrade the kernel and X of an old Puppy to achieve good hardware support.

Either build a modern Puppy or stick with an ancient version forever.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#502 Post by wanderer »

Greetings community edition puppy fans

i am presently reading the woof at github thread, and trying to learn how to make a minimal base iso from woof-ce, that can be modified and expanded into whatever we would want. This, i feel, would address essentially, all of the concerns that have been mentioned in the ce thread.

i encourage everyone to look into this option.

have fun

wanderer
Last edited by wanderer on Mon 09 Dec 2013, 15:14, edited 4 times in total.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#503 Post by amigo »

Actually, it is quite possible to support both old hardware and new software. glibc can be compiled to support older versions of the kernel. There really is no hard connection or conflict between hardware and software. Any kernel version can be run with any runtime libs you like -as long as glibc was compiled to allow support for those older kernel versions. One produces a runtime libs/progs using later versions of the libs/progs. Then, one can run any version of the kernel -which is what decides whether new or old hardware is better supported. One glibc & Co., and then the usres' choice of kernel -say 2.6.32 or 3.12, or whatever.

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#504 Post by Iguleder »

That's true, but only if you start from scratch, since it's hard to replace 2.14's kernel, glibc and X :lol:

It's wise to use glibc compiled against old headers - that's what I do in my builds. However, you also need two X stacks.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

darry1966

Re: Old hardware Base

#505 Post by darry1966 »

Iguleder wrote:
darry1966 wrote:214X just doesn't work for me.
The problematic word here is "me". Everybody has their hardware and that old Puppy that works fine for this specific setup.

Just face it! You can't support today's hardware with old software (Wary, 2.14x, any retro Puppy or old Puppy versions) and you can't just upgrade the kernel and X of an old Puppy to achieve good hardware support.

Either build a modern Puppy or stick with an ancient version forever.
1. I was talking about retro hardware and the base(s) I suggested is are proven plus Seamonkey is taken care of as browser is concerned and yes I guess I could have worded my post better instead of me statement I should have said 214x didn't work well on my crappy Sempron xorg on these Pups is far better as for newer I guess Raring or Pemasu's Wheezy - both are ready for prime time.

Just update what needs updating with 4.32 or retro 5.25 - again ideal For Retro machines.

bark_bark_bark
Posts: 1885
Joined: Tue 05 Jun 2012, 12:17
Location: Wisconsin USA

Re: Community Edition

#506 Post by bark_bark_bark »

Volhout wrote:...That means that 44% of PC's has below 4gbytes of RAM, typical 1Gbyte) and has a P4 type processor... And not the PC that was already old when puppy was launched 10 years ago.
I think the P-IV was a new when puppy came out. I think the most powerful are from 2006.
Volhout wrote:...buy new pc's.
Also, there is a problem with the "buy a new pc" statement because not everyone is "rich" enough to do so. $600 is a S**t lot to pay. $300 for a i3/i5 refurb is just too much.
....

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

Re: Community Edition

#507 Post by greengeek »

Volhout wrote: if you tear appart 214x9 you will end up with something just as instable as 214x10. Technosaurus spend a lot of time on making these versions. .
I think Ttuuxxx, not technosaurus...

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

How about resolving glibc questions via an application?

#508 Post by mikeslr »

amigo wrote:Actually, it is quite possible to support both old hardware and new software. glibc can be compiled to support older versions of the kernel. There really is no hard connection or conflict between hardware and software. Any kernel version can be run with any runtime libs you like -as long as glibc was compiled to allow support for those older kernel versions. One produces a runtime libs/progs using later versions of the libs/progs. Then, one can run any version of the kernel -which is what decides whether new or old hardware is better supported. One glibc & Co., and then the usres' choice of kernel -say 2.6.32 or 3.12, or whatever.
Correct me if I'm wrong: A Pup can also be built whose kernel was compiled to support the compiling and subsequent utilization of several glibc versions. What would then be needed are (1) a pet developer to specify in pet specs the glibc dependency of the pet and (2) a modification of PPM to examine the Pup as to whether that dependency was met.

Alternatively, perhaps you could read what I said about “Semi-Full

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

Re: How about resolving glibc questions via an application?

#509 Post by jpeps »

mikeslr wrote:
Correct me if I'm wrong: A Pup can also be built whose kernel was compiled to support the compiling and subsequent utilization of several glibc versions. What would then be needed are (1) a pet developer to specify in pet specs the glibc dependency of the pet and (2) a modification of PPM to examine the Pup as to whether that dependency was met.
Probably dependencies can be met, and still not work correctly without a fresh compile once you alter the tool chain.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#510 Post by amigo »

As Iguleder points out, the situation with the latest kernel and Xorg drivers is inter-related -this was not always so.
But, with glibc it is that glibc is compiled to accept a range of kernel versions. The kernel doesn't know or care anything about glibc -it's the libc(glibc,musl,uclibc,..) which has to understand the kernel.

glibc stable is now at 2.18. It can be compiled to use any range of kernel versions, although there are some important watershed versions where really major things were changed in the kernel. The old ways can still be supported in glibc, but do cause the libs to be larger. A reasonable approach easily lets you use kernels back to linux-2.6.32. The next big step backward in time from there would be linux-2.6.17. 2.6.16 and earlier are really different.

Next, when compiling glibc, it refers to headers which are part of the kernel source. In Slackware these are called 'kernel-headers'. In debian and others, they are called the libc-headers. They define the interface of your chosen libc with the kernel. *They do not have to be the headers for any kernel you are going to use.* They simply need to be 'sanitized' headers -if you were compiling a system with another kernel, like 'hurd', then you'd use the hurd headers, etc.

So, compile late glibc ( I still wouldn't use 2.18!) against kernel headers from 2.6.32, or 3.0..., specifying the minimum kernel version to support -2.6.32 is a nice number.

Then, compile and use any kernel version between 2.6.32 and the latest with its' modules to support any range of hardware you like or need. glibc will have no problems with any of them.

However, as iguleder says, you'd need to maintain two X stacks in order to support both old*est* and new*est* graphics cards. The fairly recent addition of KMS Kernel Mode Setting means that significant parts of the graphics drivers wound up in the kernel. These bits of code must be co-ordinated with the Xorg server version and particularly, the xf86 input an video drivers.

A similar situation exists for firmware -particularly for wireless devices. But, may distros manage to find reasonable ranges within which to work.

Now, *big heads-up*, nothing stops you from using the latest software applications you want. Your glibc version will eventually get in the way -but that takes a while usually. The point is that the versions of applications have very little direct relation to the kernel version -in fact they don't even communicate directly with the kernel.

As to the question of 32-bit or 64-bit, well, you simply need multiple package trees containing the different arches. That means maintaining two 'ports' of the (mostly)same distro. That means you need a very nice system for building and rebuilding those little units of software(called packages) -which you can then use to assemble whatever sort of system you want -based on those little logical, manageable units. The method of assembling them into an end-product or installed system, should be completely divorced from the method and system of creating those packages -and I mean any sort of bundle/app/package/sfs that you plane to use.

The one-script-to-do-it-all approach is much too messy for the job -and worse- it takes your eye off that concept of manageable, logical units of functionality which can be assembled, upgraded and extended in any way you imagine. And you still have to do that even if you have no intention to do 'dependency resolution' or provide depends info.

Every time you add something which comes from sources, you are already using the logical system -the natural order of things means that each source tarball contains a limited set of code, for a single or closely-related set of functionalities. It only makes sense to follow with that logic and create a similar object called a package which is able to correctly be installed or upgraded, and whose name and version reflects some useful logic.

If you want to have dependency info or resolution, then you need a sophisticated system for determining those dependencies -and that cannot depend on some list of dependencies downloaded from somewhere it has to be generated as part of the configure-compile-package process. Some packaging systems like arch require you to maually *supply* the list. debian building systems will generate them for you -as does t2. My package builder generates them but lets you add items which might be missed. auto-generated but tweakable. Anyway, accurate dependency information can *only* be determined at compile-time. And sometimes a bit of human input is needed. For instance, it would be extremely difficult to programatically determine that the 'man' programs needs 'groff' in order to work. It's not a binary dependency.

A LiveCD project needs really, really sophisticated package management. What makes them so hard to maintain and what makes them so prone to be 'forked' is that the method of assembling, altering, upgrading indivdual units gets abandoned. It is very easy to manually alter or programatically 'remaster' a local copy -and keep doing that for a while. But, the first time you want to upgrade, extend or down-size that one-image idea, then every custom thing that you *manually* did, is prone to be lost in your next product. And, when you release a product with a minor error, the only way to deliver the fix is to create the whole product again -one missing file means you have to upload the whole (fixed) thing again, and your users have to download the whole (fixed) thing again. And how can you upgrade such a system reasonably?

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:

Post Reply