DEVELOPERS to CONTRIBUTORS (STAKEHOLDERS) :)

News, happenings
Post Reply
Message
Author
User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#16 Post by Pizzasgood »

I guess I'm the first coordinator for the next puppy Release.
Did I not just say something about "Who died and made you king" arguments? Yep, over here.

Not to say you aren't qualified or that I wouldn't like you being coordinator. That isn't the point. The point is that I don't recall voting for you, or even saying any kind of opinion about it. For that matter, I only recall a handful of people saying anything.


Before we start choosing coordinators and such, we all need to get together and decide on some sort of structure. There's still the old Foundation (now Community?) that we can fall back on. Have we actually done this already? Again, I don't recall a decision actually being made. I may have missed it, I've been busy this summer.

BTW, why is it that all these references to the Community are on Lobster's wiki? Don't we have our own wiki? Temporary solution until we get organized?


I'm sorry to sound like Mr. We-Need-Rules-And-Regulations. I generally hate them. But we need them with this. Without a structure we will fall apart. This isn't a couple people teaming up here, this is a long term community driven project. I may not have a degree in anything yet, but I have enough common sense to know that nothing will get done without a structure that everybody involved has agreed on.


The first thing we need to do is get everybody together, and discuss whether we want to use the old Foundation structure, or create something new. It needs to give enough time for the people who only visit once a week or so to be involved (that group often includes me, though I try for thrice a week).

Then, we need to hash out how we're going to do this. Not sure if you're aware of the SVN/GIT discussion that went on earlier? We need to decide what we're going to use and how we'll use it. I'll tell you now that if it winds up being a "send your code to Mr. Coordinator and he'll assemble it all" type deal, like all the community editions we've done, then I will not be involved. We need some kind of SVN type system. Barry seems to agree.



As for email, only if anyone off the street can subscribe through an automatic process that doesn't need human involvement. I haven't really used mailing lists so I don't know if there can be permissions so that they can read without sending. We don't need to have a bunch of random fluff going through the development lists, but the development lists are also the most important to make transparent so people can see what's going on. Also there must be an online log of it (not sure if this is implied, just making sure).


May be easier to just use a development forum. Probably would be good to be a separate forum from this one, for traffic considerations. Not private! In fact allow anybody to sign up. But strongly discourage any fluff. Off topic and generic requests for help belong over here and should be ignored, other than maybe telling them that they're in the wrong place and providing a link to here. ttuuxxx, please don't run off and create one overnight. I know you're chomping at the bit, but hold your horses. This isn't a race; there's no need to rush. People might want to propose recommendations about what forum software to use, etc.



I might run my own personal projects with a fly by the seat of my pants mentality, but there's a big difference between a one-man effort and a long term group project that is intended to be used by many hundreds of people! This needs Planning.








Somewhat back on topic, we do need to find out who is interested in actually doing development stuff. I am. I won't support a half-baked scheme, but given proper planning I will do what I can to help out. The first item on my radar is fixing the bug where Xorgwizard only halfway configures xorg.conf for a dual-monitor setup. It should either go all the way, or not make an attempt. Either one would result in a WORKING xorg.conf file. But the halfway approach results in a broken file that I must correct by hand every time I boot with pfix=ram or a fresh install.

This may also be an issue for people who have only one monitor, but both an onboard graphics chip and a separate graphics card.


Otherwise I haven't used 4.xx enough to know what the current issues are. Until halfway through this summer I was still using a derivative of 2.14 for daily use. One thing is that ever since we dropped Xtmix (I think it was Xtmix - the one with the retro look) I've been wholly unsatisfied with Puppy's volume controls. Just haven't gotten around to writing my own, as Alsamixer gets the job done right the first time. But it would be nice to have a proper mixer in the tray. That's something I could do. I've shied away from learning to use GTK with C/C++ for too long anyways. Need to get it over with, as that would open up many new projects to me.

I could also tweak the PetGet manager to have the functionality of Pet-Be-Gone built in. Barry had actually intended something similar from the beginning but never got around to it.

The unleashed createpuppy script needs some work too. I have a crudely hacked local copy that can read the configuration from a config file and then do the build automatically, as opposed to asking a million questions every time, which always annoyed the carp out of me (don't know how the carp got into me though - I hardly ever eat fish...). Mine is crude, I basically just hardcoded it to read from the file and not ask questions. A proper solution would ask if it should ask questions or read a file, and have a default file but accept others. This way one can build Puppy more reproducibly, because you don't have to worry about accidentally putting in a different choice during each build.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

Trobin
Posts: 968
Joined: Fri 19 Aug 2005, 03:16
Location: BC Canada

#17 Post by Trobin »

Yup, the knives are out and being sharpened.
[url]http://speakpup.blogspot.com[/url]

Trobin
Posts: 968
Joined: Fri 19 Aug 2005, 03:16
Location: BC Canada

#18 Post by Trobin »

I do hope that you manage to sort it ouit. It would be disappointing to see Puppy go the way of other distro's after their main developer(s) stepped aside.
[url]http://speakpup.blogspot.com[/url]

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#19 Post by Lobster »

Pizzasgood wrote: I don't recall a decision actually being made. [/b] I may have missed it, I've been busy this summer.
.
Hope you had a good summer Jeremy on the farm. :)

The situation is one of availability. Tronkel has kindly suggested me.
I couldn't run aground, if you paid me.
I would prefer MU or you, Sigmund, HairyWill, one of our other developers, Warren, Raffy etc Someone who is able to work on Puppy with the energy he deserves.

Ttuuxxx has kindly offered to put his considerable energy and diplomatic skills (in development) into 4.2

No one else has shown any inclination
It is very difficult to vote without candidates. Do we have any?
BTW, why is it that all these references to the Community are on Lobster's wiki? Don't we have our own wiki? Temporary solution until we get organized?
Very much temp, I hope.
I use my wiki because I am familiar with its operation
When using the new community wiki I have to think about the wiki rather than the content.
Defeats the purpose. :?
I did the same with PSIP and them moved it to the community wiki
So I have suggested a member of the community start a 4.2 page on the community wiki. My content is freely available to them . . .
Without a structure we will fall apart.
Our structure (of parts) is in place
I spend all my time falling apart :lol:
The first thing we need to do is get everybody together
Maybe someone will play that part?

We need some kind of SVN type system.
What are the choices? Where is the poll?
Can this go on the agenda?

May be easier to just use a development forum. Probably would be good to be a separate forum from this one, for traffic considerations.
We have had several of those. One was used reasonably extensively.
Perhaps this one?
http://www.freelists.org/list/puppy-devel

I will do what I can to help out.

Hooray!
I hardly ever eat fish...
Heretic! :oops: [must remember there is other food from fish]
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

User avatar
tronkel
Posts: 1116
Joined: Fri 30 Sep 2005, 11:27
Location: Vienna Austria
Contact:

#20 Post by tronkel »

Let's have a quick recap of how Barry does things.

He's not in favour of a formally project-managed Puppy project at all. He maintains that this does not encourage the creativity that Puppy needs in order to hold on to its commanding lead in this distro playing field.

He created the basis of the base versions single-handedly. Other very creative contributors from the forum also offered up various sub-projects which he either took up or declined according to as he saw fit. The point is, Barry was the sole creator of the basis of the base versions. I don't believe anyone else in the forum has the exact skill set to implement a base version as such. There are many who can chuck out a puplet unleashed or re-mastered "community edition" but none who could come up with an innovative base version complete with its current devx_sfs and unleashed core. I think I'm right in saying that Kirk has experience with T2 and is a good scripter as well. He is the exception here.

So Jeff needn't be surprised here that no-one is offering up their services to create the proposed 4.2 base version. Also, this category of "developer" cannot be found in the forum embodied into one person. Head-hunting elsewhere might be an option here.

If the project gets structured in the form of a "leader" who does the herding, plus a committee/developer team I reckon Puppy will not get used as much as it is now and will eventually die off. The only proven system is Barry's informal structure. The Puppy that will really get used is the version(s) that Barry will make in his part-time role - in whatever form they appear.

IMHO any post-Barry leader of the project will need to have a skill set and philosophy very similar to Barry's

Anything short of this and the puppy distro will sink without trace after a protracted dying-off period.

In the meantime. I still say that Lobster makes the best front man for Puppy at least for now. He's the only one who doesn't take himself seriously and has the good humour that the job requires. Any cats with any spare fish, please donate to the worthwhile Puppy cause.
Life is too short to spend it in front of a computer

User avatar
cb88
Posts: 1165
Joined: Mon 29 Jan 2007, 03:12
Location: USA
Contact:

#21 Post by cb88 »

well .... regardless of above and past arguments we do have an svn

you can get acces from me by PMing your sourceforge unix account name

all you need to do is figure out how to use it SVN that is i haven't the time between a datastructures in java and engineering statisics

I do however have time to do what very little management is needed with the sourceforge page which up till now is just adding a few people to access it

i have compiled T2 with 686 optimisations and the binaries that i tried out in slackware seem very fast compared to plain slackware so multiple builds will be of interest

a T2 profile to generate a livecd would be very welcome and probably imperative to compete with the likes of the debian livecd remasters which will likely be very fast and have a huge applicaton base

most people are behind either T2 or gnomeslack... IMO T2 doesn't really hurt us since slackware has a pretty pittiful package selection anyway due to the fact that most of its users compile thier own apps on the other hand with T2 we can easily tweak out entire kernel to what ever we want VERY easily and rebuild time is not *that* bad ...like 3.5 days on a dual PII for the piglett base running slackware

FINALLY! what do we need to have on SVN?
3 things at least for now
-piglett T2 profile (will need updating to T2 8.0 when it is released currently we are using T2 8.0 trunk as of late 2007)
-archive of all puppy apps/scripts
-unleashed scripts (might be replaceable by T2 itself) ... plan integration by 5.0?

what do we need other than T2? a source snapshot !!!
it would be much appreciated if someone would download and host a .bz2 or .lzm of the full T2 source not just the basics BEWARE it might get HUGE multi GB of source the puppy base it self is a tar over 1gb!

it might be prudent to wait for the 8.0 release to do this snapshot...

as always these are sugesstions so what do you think?

on a side note slitaz it VERY interesting it claims to boot with only 5 scripts and a config file.... are the boots scripts that tiny in puppy? in anycase we absolutely need better documentation on how barry scripts and how linux boots in general
Taking Puppy Linux to the limit of perfection. meanwhile try "puppy pfix=duct_tape" kernel parem eater.
X86: Sager NP6110 3630QM 16GB ram, Tyan Thunder 2 2x 300Mhz
Sun: SS2 , LX , SS5 , SS10 , SS20 ,Ultra 1, Ultra 10 , T2000
Mac: Platinum Plus, SE/30

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#22 Post by Pizzasgood »

My beef isn't about who is in charge or what structure we'll have. It's that we need to actually make known when we're making a decision, and then give people a chance to provide their input.
Ttuuxxx has kindly offered to put his considerable energy and diplomatic skills (in development) into 4.2

No one else has shown any inclination
It is very difficult to vote without candidates. Do we have any?
Not that I'm aware, but how long had it been? Three days or so? Besides which, I wasn't even aware that we were making this decision now! I thought we were still trying to pin down how things would work so that we'd be able to make an intelligent decision afterward. Maybe we don't even want to do a coordinator approach. Maybe something completely different would work better. But did we get a chance to discuss it? Maybe for a day or two. Woopdeedoo.

I have a lot of respect for you Lobster, but sometimes you rush things too much. There's a limit to how fast we can go and still keep everybody in the loop. And this is coming from a guy who's favorite fictional character is Sonic the Hedgehog...



well .... regardless of above and past arguments we do have an svn

you can get acces from me by PMing your sourceforge unix account name

all you need to do is figure out how to use it SVN that is i haven't the time between a datastructures in java and engineering statisics
Yes we do, I didn't forget that. It will be useful too. But I'm referring to something that can hold the entire Unleashed Tree, which I'm nearly certain is beyond what SourceForge will let us do. I could be wrong of course.

As far as I'm aware, the only reasonably efficient way to have multiple people working on this, while avoiding collisions, maintaining an accurate record of exactly what has changed and who changed it, and making it easy for anybody to follow along, is to put the whole unleashed tree into SVN or GIT. Technically it would probably be most efficient to split the packages directory from the unleashed directory and have them side-by-side on SVN, so that people can checkout the unleashed directory itself without grabbing the data for all 500 packages. Like I said on the thread you started before, the SourceForge SVN would then be used for all the stuff that doesn't fit inside unleashed along with the unique-to-Puppy applications. Things like T2, the P* applications, maybe Pebble 2.0 if I ever get around to that, etc. The Unleashed SVN would include the binaries of those, along with any tweaks needed (different default preferences, etc.) Actual development of the apps would go on at SourceForge, and the binaries could be imported when ready. The misc. scripts in Puppy would only be in the Unleashed tree of course. Just the full-blown applications would be on SF. Things that could actually stand on their own without Puppy, more or less. Especially ones that are using a compiled language, since the Unleashed SVN would not involve source, just as Unleashed doesn't. T2 and the SF repo would take care of that, for now.

If we used GIT, we'd probably want to structure things a little differently. The main advantage I see with GIT is the private branching, which would make it much easier to test stuff without messing with the trunk. That has the drawback of needing somebody to maintain the trunk and handle merging things into it from the various testing branches. That makes me think of the whole Coordinator thing, but this would have stronger technical requirements as he'd need to be able to read through the segments of code and figure out what the two people were doing and how best to combine them... Probably not a big issue with the small number of people that will be involved though.

An aside to Lobster: AFAIK the choices are CVS, SVN and GIT. SVN is basically the next version of CVS. GIT is more distributed than SVN, which has advantages and disadvantages. Might be overkill for Puppy, as I don't think we'll have enough people involved for that to help more than it will hurt. If we did have a lot, I'd vote for it. At the moment I'm leaning more towards SVN since it's simpler to understand and will probably take less work to use. That would also keep things consistent with the SourceForge repo. If you dig up the thread where cb88 announced the SF account for Puppy, I posted more on how I thought this could work.


Back to cb88: And you bring up a good point about combining T2 and Unleashed. I think that integrating T2 into Unleashed is definitely a long term goal we should work towards, assuming with stick with using T2. It would be nice to download something and be able to type make and have it build the default Puppy, fully populate Unleashed, and assemble a new ISO. Having it correct any scripts that need correcting for various kernel configurations would probably be going too far, so things would still need some manual intervention for some customizations, but in general it would be great.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#23 Post by ttuuxxx »

I'm all for T2, I played around with it and it worked nicely, Git on the other hand I only used it once on puppy 4.0, to compile VLC 9.1 After many downloads and tons of time compiling, VLC didn't work.
I have a good feeling its puppy's default compiler. But VLC isn't everything. ttuuxxx

PS It would be nice if we went back to Slackware, I was thinking Ubuntu, but the thing about that, Ubuntu breaks their packages into smaller package sections and they use more dependencies. Thats why slackware, Plus Gslapt is easy to get going on puppy. maybe based on the 12.1?
Just an idea, tossing around
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
cb88
Posts: 1165
Joined: Mon 29 Jan 2007, 03:12
Location: USA
Contact:

#24 Post by cb88 »

so what you really saying is that you are lazy and don't really care if you make the best product you can?

you obviously completely ignored my post... slackware is old hat and there really aren't many packages at all for it puppylinux itself seems more active in that area if it weren't for the duplication of efforts (due to non automated package generation due to lack of T2 integration etc...) we would probably far outclass slackware for official packages

with T2 building packages automatically i may be as simple as updating a source link md5 hash and rebuilding the package

@pisszasgood unleashed is pretty much just a set of scripts to create teh packages list and squash the root filesystem and put it on the ISO among a few other things correct? The base core and kernel are usually in unleashed i know but that would be handed off to T2 to generate or we could build default/release versions of unleashed that are just like what we have now

@also at pizzasgood :-) i never intended for binaries to go on sourceforge that would be pretty silly since the whole idea is to get a system going where we can build LOTS of different versions of binaries different optimisations that people can host as thier own truely custom versions of puppy on thier own server space if they want

I guess all the official packages will remain on sourceforge and will be build by someone trustworthy from the default T2 profile then uploaded

also i believe that barry has hinted pretty strongly that an automated build from T2 was kindof in his goals anyway

@ttuuxxx using Slackware as a base may be easy but you have to think of the trade offs... Slackware packages are not easy to get working I know because I use Slackware as my every day system and if there is a lib missing from a package it is a pain in the butt to find and get the right version etc........ so by choosing Slackware you get an easy job of building puppy in you opinion anyway and offload the work onto the extra packagers and the users. I am really skeptical of your *project management* skill since you didn't think that through and you really do lack diplomacy sorry to give you heat here but I just don't agree with you.
Taking Puppy Linux to the limit of perfection. meanwhile try "puppy pfix=duct_tape" kernel parem eater.
X86: Sager NP6110 3630QM 16GB ram, Tyan Thunder 2 2x 300Mhz
Sun: SS2 , LX , SS5 , SS10 , SS20 ,Ultra 1, Ultra 10 , T2000
Mac: Platinum Plus, SE/30

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#25 Post by MU »

search files:
http://packages.slackware.it/

Enter the name of a lib, check "file name", and you should find it.
Slackware has huge repositories, what is not listed in the official repository, can be found on other sites.
browse:
http://ftp.ntua.gr/pub/linux/slackware/ ... slackware/
ftp://ftp.slackware.org.uk/gsb/gsb-curr ... /packages/
visit:
http://linuxpackages.net/

And if something is not available, just compile it from source.
In Puppy I often had trouble to compile stuff, this has become much easier, since I replaced almost everything with slackware packages.

Mark
[url=http://murga-linux.com/puppy/viewtopic.php?p=173456#173456]my recommended links[/url]

User avatar
cb88
Posts: 1165
Joined: Mon 29 Jan 2007, 03:12
Location: USA
Contact:

#26 Post by cb88 »

@Mu i am well aware of those and slackware is still lacking :?

I have often browsed linuxpackages and many other repos for libs...COMPLETE waste of time

think of it this way Debian = {all packages have deps automatically resolved.... 0 wasted time for the user slight overhead on the developer to make sure the deps are available big deal}

slackware = {I have the libs here is a package i made hope it works! then 3 or four dependancies are missing and you are up a creek compiling stuff.... the user has to be able to compile just to use it]

IMO using slackware is just spinning your wheels if you need more than the defaults (which i don't... right now)
Taking Puppy Linux to the limit of perfection. meanwhile try "puppy pfix=duct_tape" kernel parem eater.
X86: Sager NP6110 3630QM 16GB ram, Tyan Thunder 2 2x 300Mhz
Sun: SS2 , LX , SS5 , SS10 , SS20 ,Ultra 1, Ultra 10 , T2000
Mac: Platinum Plus, SE/30

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#27 Post by Pizzasgood »

Unleashed itself is a small jumble of scripts that takes all the packages making up Puppy, combines them into one directory, and builds a squashfs file from that. But the Unleashed Tree is a clean organized way to edit the packages that will be merged to create Puppy. You don't just run T2 and then it builds a Puppy, yet. A lot of manual work goes on between T2 and running Unleashed's createpuppy script. This is the stage I'm talking about putting inside of an SVN or GIT repository.

Eventually, I do hope we have T2 set up such that it will make that middle stage unnecessary. At that point all we'd need is the SVN/GIT repo holding the Puppy-specific T2 stuff. That, I believe, would be fine to do with SourceForge.

But I'm under the impression that that's still a good ways in the future, if it's even a practical thing to do. I may be wrong. I still haven't had a chance to play with T2. Too much real-life stuff at the moment. It's on my near-term todo list, but could still take a month before I get to it. Hopefully more like two weeks.
i never intended for binaries to go on sourceforge that would be pretty silly
Exactly. We'd develop the Puppy specific applications there, and we'd put their binaries into the Unleashed tree which would be hosted elsewhere. In the future we'd grab and compile them through T2, making a separate SVN/GIT repo unnecessary.


Assuming we stick with T2. I won't have a real opinion either way until I've used it. But being able to recompile everything, say for a 64-bit architecture or for PowerPC, would be pretty handy I think.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
cb88
Posts: 1165
Joined: Mon 29 Jan 2007, 03:12
Location: USA
Contact:

#28 Post by cb88 »

yeah I haven't gotten much past compiling (which is pretty easy with T2)

I wanted to try barrys scripts to build packages but just don't have the resources (time at home or a laptop... not that even haveing a laptop i would still lack time LOL)
Taking Puppy Linux to the limit of perfection. meanwhile try "puppy pfix=duct_tape" kernel parem eater.
X86: Sager NP6110 3630QM 16GB ram, Tyan Thunder 2 2x 300Mhz
Sun: SS2 , LX , SS5 , SS10 , SS20 ,Ultra 1, Ultra 10 , T2000
Mac: Platinum Plus, SE/30

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#29 Post by Lobster »

Lob:
It is very difficult to vote without candidates. Do we have any?

Pizzasgood:
Not that I'm aware, but how long had it been? Three days or so?

Over two and a half years since Barry announced his retirement.
During that time a developer with the time and inclination has not yet emerged organically . . .

Just as the numerous attempts for an SVN system have been tried (even implemented - I have tried about 5) but never adopted.

It is why I suggested tick
http://www.murga-linux.com/puppy/viewto ... 033#221033

Any news on that from Prithish?
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

NathanO
Posts: 210
Joined: Fri 23 Feb 2007, 00:03
Location: San Antonio, TX

4.2

#30 Post by NathanO »

Ttuuxxx,

Did my e-mail get to you, been having problems with outgoing e-mail.

If it did not I will post here or PM as you wish.

NathanO

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

Re: 4.2

#31 Post by ttuuxxx »

NathanO wrote:Ttuuxxx,

Did my e-mail get to you, been having problems with outgoing e-mail.

If it did not I will post here or PM as you wish.

NathanO
Sorry Nathan Yes I did, thanks for that, I'll contact you back shortly.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#32 Post by big_bass »

you can finish the CE you started

that would be a good first step


big_bass


*edited to remove a url link
Last edited by big_bass on Thu 09 Oct 2008, 16:28, edited 1 time in total.

User avatar
HairyWill
Posts: 2928
Joined: Fri 26 May 2006, 23:29
Location: Southampton, UK

#33 Post by HairyWill »

I think it is great that we are talking about this.
This thread title needs to be changed from DEVELOPERS to CONTRIBUTORS (STAKEHOLDERS).

Who gets a say?
What do you want?
What what you like to contribute?

Who would you like to work with?
How should future collaboration be organised?
Many of the best inovations in puppy have been when one or two people work on their own. We DO NOT have successful experiece of large scale collaboration.
Is the future a series of forks?
Would these forks divege or could they run parallel? I believe that a large number of minor architectural decisions will cause them to diverge unless steps are taken to counteract this.
I have been posting here for 2.5 years and still only have a loose grasp on who is an expert at what.
Those with the loudest voices are probably ill equiped to speak (including me). Now is the time for everyone to stand up and answer my first three questions.
Will
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]

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

Notes on Compatibility

#34 Post by amigo »

I thought it might be helpful to clear up a few misconceptions about compatibility of any future version with other versions/distros.

Compatibility is not one thing -there are 4-5 different aspects to consider.

Being 'fully compatible' with a Big Brother distro would basically entail creating a spin-off much like Knoppix, sidux or DSL which in theory can mostly be built using the official debian depositories. I think it highly unlikely that this is really what anyone wants for Puppy. That level of compatibility is bound to cramp the Puppy style.

There are 5 kinds of compatibility to consider:
1. Binary compatibility
Contrary to what many people think, binary compatibility has little to do with the kernel version or the compiler version. Binary compatibility means that a program or library compiled on one OS will still run on another OS version -like compiling a program on a redhat system and then running it on Debian. This compatibility is nearly 100% dependent on the *glibc* version which was used while compiling the program or library. The glibc version is at the heart of the system. Often, when glibc is upgraded by a minor version number, compatibility is not maintained for programs which were compiled using another version of glibc. As an example, Slackware-8.1 used glibc-2.2.x (which used to be called libc5). Later versions (up till 12.0) used glibc-2.3.x. Programs which were compiled on Slackware-8.1 with glibc-2.2.x will not run under Slackware-9.1 and later versions.
The compiler version used to create the glibc for a distro is important, but not limiting. You can still use other compilers to create binaries using the new version of glibc. The kernel version is also pretty much non-critical -except that using glibc>=2.4 will require a 2.6 kernel. What is more important is the version of kernel-headers used to compile glibc with. When you start a new distro, the fresh glibc must be compiled using some headers which come from the kernel. But, the version of the headers does not have to be the same as the kernel version!

The first critical choices to make involve choosing versions of glibc, compiler, binutils and kernel headers which work together well. Simply choosing the latest version has never, ever worked. Here is where a little study of self-build projects and/or current major distributions pays off handily. You should always start with versions of these which have been proved to co-operate well. But, when compiled, the glibc version, its' options and the kernel-headers version used is what determines whether programs you compile will be binary-compatible with another distro -or vice-versa.
While it is possible to use another version of gcc to later compile programs with your new glibc, the choice of main compiler and its' location in the filesystem are essential to compatibility with libstdc++ -that's the libs used for programs which are written in C++. This is where binary-compatibility gets really sticky, because C++ programs are much more closely tied to the libstdc++ libs produced when compiling glibc. These libraries are compiler-dependent. The ld-linux program produced along with glibc, will try to link programs to be run to the glibc version and to the location of the compiler libs(libstdc++) -although these can simply be placed in the normal library search path.

In summary, the glibc version is the one thing that really 'defines' a major release of an OS. Changing the glibc version always entails re-compiling quite a few of the standard programs. Changing the kernel version is pretty much independent. The binutils and compiler version are chosen to accomodate them with the glibc version.

The trinity of compiler-binutils-glibc versions is what is known as a tool chain. For a fresh distro, these three items should all have been comoiled using each other. This can only be done with multiple passes. After that, all the programs for the new distro are built using the same toolchain and using the same kernel-headers which wre used for compiling glibc itself.

2. init script compatibility
There are basically three types of init system in common use. Debian uses an LSB-compatible system. SysVinit is used by redhat and most other distros. Slackware and its' derivatives mostly use what gets called BSD-style init. It really is a SysVinit, but the scripts are much simpler and easier to work with, similar to the those used by BSD.
Since init processes are controlled using shell scripts, differences between the various systems can nearly always be worked out, but this must usually be done manually. Programs which use the redhat-style SysVinit system have to be modified to run under debian-based systems.
Puppy, being a LiveCD has a basic init style which is very different from any standard distro, but what I am referring to is more about accessory programs than the basic functioning of the init process. Programs which are usually called 'services', like servers and other such, which must be started during bootup, use scripts in /etc/rc.d under Puppy. The Puppy style use of /etc/rc.d is most similar to the Slackware-style -but Slackware includes compatibility with redhat SysVinit-style init scripts. And, in fact, LSB-compatibility can also be included. It is possible to use all three types on one system, but that would make a pretty confusing system. Most users don't have to worry about this -only dvelopers and maintainers of the common services programs would need to have a good understanding of all this.

3. Directory layout compatibiblity
The situation here is better than it ever has been. Most distros are using mostly the same locations for important files. There used to be a lot of diferences with KDE being installed under /opt on some systems, with GNOME being installed under /opt on some and under /usr on others. The main remaining diferences these days, invlove the placement of shared data, doc, man-pages and info pages. Again, debian follows the LSB stabdards and places docs, ifo and ma-pages under /usr/share/(doc,info,man). Slackware uses /usr/doc,info,man and the redhat distros vary between the two. the placement of all these files is usually non-critical -that is at runtime, compiled programs
or libs don't know or care where these files are located. there are exceptions where programs make direct acces to documents(like help files), but these locations are alway configurable at compile-time. And converting most packages to another directoiry layout is usually no problem -except for the shared-data location and the prefix. The shared-data and prefix are often hard-coded into programs and libs at compile time, but these are also configurable (or can easily be changed with a simple patch)

4. package format compatibility
You can use rpm as a package format without the packages being compatible with other rpm systems. The same for using dpkg -using it doesn't necessarily mean your packages will be comopatible with debian-based systems. But, if you hope to have your new distro have binary or full compatibility with any other distro, you will almost surely want to use the same packaging format as that distro. Yoh may use alternate tools to create packages of the same format. the alien program does a pretty good job of converting packages between formats -it does so by using the same tools as the donor and target distro.
Package format is still a great weakness in Puppy. The two formats of pet and pup are both faulty. pets are weak on install-time options and pup's have maybe too many install-time options. It is ridiculous to have to create 5-7 files and archives to go with your finished program, like with pups. pets, on the other hand, have little facility for performing actions at install-time which are needed with lost of programs. The debian system is rich with such features without being tooo burdensome. Slackware packages offer the chance to include a doinst.sh script which can perform extra actions when insatlling a package(just after unpacking the script is run.) Debian offers even more chances, because packages are first unpacked in a temporary directory before being moved/copied to their final destination. this allows for a chance to backup files which we bill overwritten by the new package. Debian also also allows for two separate scripts which can be run when removing a package -one before and one after removing the package. rpm packages also offer similar options.

Choosing or creating a package format and package management system are extremely important. The lack of an easy-to-use, but feature rich installation method has always been a big fault in Puppy. And ease-of-use must also translate into easy-to-create. developers should have acces to an easy way of packaging their programs.
Most are aware that Slackware package management involves no resolution of dependencies, although third-party tools can add this capability. rpm distros have the bad fame of causing dependency-hell. Debian has the good fame of having nearly faultless package management which lets you dependably upgrade or even downgrade at will.
Designing and maintaining a true package management system which resolves dependencies is a nightmare and invloves a tremendous amount of work and testing. Maintaining a single database (like swaret) is one of doing it. But then each system must have the up-to-date database installed in order to use it. rpm and debian systems use in-package information to provide dependency resolution. doing it this way means that every person who creates or mainatins a package has to know how to correctly provide that info and keep it up to date.
A central database is somewhat easier to manage and can be done by less people, but it may be harder to keep it truly up to date.

I've just thrown this together to tickle your thinking a little. I may add to it or edit it later if their are questions, addtitional points to make or inconsistencies.

You can choose between any or all of the above aspects independently of the build environment. In other words, you can build a complete slackware-compatible system using a T2 build environment. Ot any other combination you choose. If you do the thing properly, the new toolchain is built first and everything that follows gets built using that toolchain -no matter which system is hosting the build. Once you new system is up and running at a level where it can reproduce itself, ther is no more need to run the original host system.

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#35 Post by ttuuxxx »

I have to agree with you Amigo, Oh so many times I've gotten incompatibilities with Glibc, Thats where it sits with big brother distro's. also I think that puppy only has 2 people who could pull off a successful base in a timely manner, Nathan O or cb88. Nathan also has local linux support group who could help him out. I'm not sure if they would want to take on something like that? In the past I've mentioned on numerous occasions Maybe Ubuntu Intrepid, as the big brother and then Barry even mentioned that his future project might use that as a Big brother distro.
I personally think if both parties keep to the same platform and move in the same or separate directions after that it could be very helpful for both of parties. I've always liked the ubuntu repo. Its well laid out. Probably the best linux one. I don't like how broken down each package is. They even break down single applications. http://packages.ubuntu.com/intrepid/ How do others feel about it,? When it comes to debian, http://packages.debian.org/stable/

Something else I was thinking about, It would be nice if Puppy kind of stuck with one series for maybe at least 12months maybe be more. It would give it time to mature better. If we kept our resources focussed on one model with patch releases, wouldn't that give us a better working Os, we went from 2.17 to 3.0,3.0.1,4.0 in about a year or a bit less. Its too bad the 3 series was so short lived, I've read numerous times how people really enjoyed it being slackware compatible actually never read a complaint against it!. Sure Slackware doesn't have a large repo that Ubuntu or Debian have but. Slackware binaries have less dependents after the first initial extra libs, Plus the main packages that most people want, Slackware usually has them. Puppy will always be independent of other distro's I feel because of all the extra programs we have from our excellent developers and trouble shooters, like Pfind, Pburn, Puppy package manager, Plus wireless fixes and nonstandard screen resoutions etc these unique packages
combined with colourful community is whats makes Puppy so great and unique. So when it boils down to it, If puppy was to have another big brother distro, Debian, Ubuntu, Slackware its all good :)
As for puppy 4.2 or 5.0 being the next model number should we continue with what Barry has started, or should be go with a new model compatible with a big brother distro? Start fresh ? for 5.0 but we could actually move closer towards Ubuntu Gutsy if we stick with 4.0 series since it uses the same Gilbc as puppy 4.0 and is already mostly compatible. http://packages.ubuntu.com/gutsy/
These are just ideas I'm tossing out, Something to think about.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

Post Reply