Lessons to learn from Slitaz

[jemimah]

Puppy has a wiki. I think you just have to PM Raffy for an account.

http://puppylinux.org/wikka/HomePage

If someone were to create such a page, and add all the existing packages, probably it wouldn't be that hard to get people to keep it updated in the future. I think many packages are already in there.

[prehistoric]

Writing for the wiki is an excellent practice, which I have been remiss in doing. My excuse has been that things here on the forum move too fast for me. I am constantly discovering I'm simply repeating information already posted.

One thing I'm looking for is a sneaky way to index this forum, by taking advantage of searches people run and questions they post, so that writers of wiki articles won't have to repeat searches or experiments. Luis von Ahn, the main originator of the reCAPTCHA idea, is now working on ways to use humans to classify pictures (without necessarily turning it into work, and paying them.) Using the many people learning about Puppy to generate classifications of posts in a more limited domain, without making it into a job, seems like an easier problem.

At present, I'm having enough trouble keeping up with work by Jemimah or Zigbert in current threads. When you consider the many forks in the path to the latest and greatest Puppy, and realize these are not necessarily dead ends, the problem of providing appropriate advice for people who want to pursue alternatives gets considerably larger.

One current example is a question about a machine with very limited RAM and disk. John Murga's meanpup 2.02 still sets a hard standard to beat. But, what if you don't want to boot off a CD, or can't? If I had not faced exactly the same problem recently, I would not have known where to direct someone to the posted answer.

One recurrent theme in the current topic has to do with libraries. We keep hearing, over and over, pleas to offer a repository like Ubuntu, etc.

What needs to be emphasized is that we are not cut off from these. The Puppy 3 series could use packages from Slackware, if you handled dependencies properly. There was also gslapt, which could install packages from Debian, thanks to MU. Not only was this possible in the past, there are still forks of Puppy proceeding along those lines. Big Bass has been running Slaxer for some time. Now, with woof, we have whole new series built from Slackware, Debian, or Ubuntu packages: spup, Dpup, upup.

In addition, I want to mention ttuuxx turning out upgrades for the 2.x series, and technosaurus' or jrb's work with tinycore. (Is this tpup? Anyone I've overlooked, please forgive me. I haven't been able to read the entire forum.)

We have all manner of programs available, we just don't put them in the official release. Much of the work of sorting out changes from other distributions is thoroughly routine. It shouldn't require the attention of a special "developer" who designs and writes programs for a living. Most people who come to Puppy are willing to do a modest amount of work to get something they want. How can we build on this to make this work available to others who come later -- without creating a rigid organization?

[106498]

I guess there's no reason not to put it on the main wiki (other than that no other linux does this AFAIK, but then again, this is puppy:-)

I'll go request an account right now. And learn how to compile stuff.

The reason it's hard to uninstall things is that the sfs file is read-only. To actually delete stuff, you have to unpack it, delete the files, then repack it - which you cannot do on a running system. You're better off starting with a barebones system, and adding stuff from there.

I guess thats true. In that case it would be nice to have an official barebones, although that's probably not feasable. I found that most barebones distro's still had some random unnecessary programs (games etc, I really can't remember exactly).

Looks like I'll have to learn to use woof.

[ttuuxxx]

I guess there's no reason not to put it on the main wiki (other than that no other linux does this AFAIK, but then again, this is puppy:-)

I'll go request an account right now. And learn how to compile stuff.

The reason it's hard to uninstall things is that the sfs file is read-only. To actually delete stuff, you have to unpack it, delete the files, then repack it - which you cannot do on a running system. You're better off starting with a barebones system, and adding stuff from there.

I guess thats true. In that case it would be nice to have an official barebones, although that's probably not feasable. I found that most barebones distro's still had some random unnecessary programs (games etc, I really can't remember exactly).

Looks like I'll have to learn to use woof.

Yes woof sounds like a perfect project for a eager person like yourself
good luck, its a lot of fun once you get into it
ttuuxxx

[amigo]

"puppy teaches more newbees real Linux internals" -Sorry, that's the wildest staement I ever heard -you can't pass on what you don't have... Puppy still has no concept whatever of Linux internals

[nic2109]

As ever we are a morass of contradictions.

"Yes, we love freedom" and "Yes, we want someone to impose order".

It's wonderful that Puppy has so many flavours and possibilities, and it's infuriating how hard it can be to find things.

If I recall Ubuntu correctly it gives you the option to specify the Repositories you wish to include in the scope of any search: whether "Official" or otherwise (sorry, I can't remember the actual terminology). I assume that this is inherited from Debian. Can this concept be used in Puppy to give the choice people seem to want?

The timid/newbie/person_who_just_wants_a_working_system can stick to the official repo, while the more adventurous can extend to include others. Meanwhile, Developers can put stuff in a suitable place, but only "approved" packages can get in the official repository. (Yeah, I know that raises the huge question about testing and approval and so on. But that's a subsequent issue).

Yes it would take some organizing and discipline, but it might be possible to approach something that suits both camps.

Nick

[jemimah]

"Yes, we love freedom" and "Yes, we want someone to impose order".

We'd like someone to create order, but not impose it. Order should be optional to protect the interests of those that prefer chaos.

[nic2109]

"Yes, we love freedom" and "Yes, we want someone to impose order".

We'd like someone to create order, but not impose it. Order should be optional to protect the interests of those that prefer chaos.

That's a fair cop. Available but optional seems like a good stance.

Any volunteers for order creation duties?

[prehistoric]

...Available but optional seems like a good stance.

Any volunteers for order creation duties?

If you write an ad like the following, it would be best to be cautious about meeting applicants:

Heroic Martyrs Wanted

C. Northcote Parkinson wrote an essay titled "The Short List" about how to find people for difficult tasks. It would be well to remember his conclusion after discussing a successful applicant for one example position: "He's off his head, but that can't be helped."

[nic2109]

Ahem....... we seem to have gone a long way off topic.

Is the issue of package management exhausted? There seems to be general consent that Slitaz (among others) has better package management but wild disagreement about whether it's worth emulating.

Is this really the end of the discussion? I really cannot see that robust and flexible package management threatens the freedom many yearn for, but it can give the stability that others seek. Is it really that difficult?

[prehistoric]

...There seems to be general consent that Slitaz (among others) has better package management but wild disagreement about whether it's worth emulating.

Is this really the end of the discussion? I really cannot see that robust and flexible package management threatens the freedom many yearn for, but it can give the stability that others seek. Is it really that difficult?

The problem, as I see it, is not really the package management software, with the exception of some obvious bugs which can and should be dealt with. The problem lies in that repository of officially-sanctioned packages known to work without problems.

What I wanted to emphasize is that Puppy is not limited in the way many other distributions are. BarryK has created the roots and trunk of a tree with many limbs and branches. He has declined to trim this into a pole with a single path of development.

You are entirely free to create a repository you like, with your own choices and standards. You can post about this in the forum and wiki. You can set out your own manifesto of purpose. You can recruit others to your cause, even using this forum. You can borrow code from all over. You can modify a puplet to work exclusively with this repository. You can create your own package management system.

What you cannot do is call this the one and only official Puppy repository. Fights over control have crippled such promising software development projects as Gentoo Linux. Barry has gone to some lengths to avoid this.

"MU" created a substantial fork from the Puppy 3.x series called Muppy. "Big Bass" has a fork from 4.12 called Slaxer. "Ttuuxx" is supporting projects from the 2.x series to the latest development. As far as I know, Barry is on good terms with all of these people.

The hidden agenda of some people who call for standards is an attempt to force others to do things their way. They may not even be aware of this motivation when they start out, but it shows up with depressing regularity.

Go back to fundamental documents and you will see the statement "Puppy is an evolutionary system". The development process we follow is as messy as organic evolution, the results are uncertain, but we are doing better at innovating than a great many sizable organizations.

If you have ever been part of such an organization, you will immediately recognize the truth of this observation: you can say many things about software development in such a context, but you would not call it fun. This is the missing ingredient which brings developers to Puppy, and turns users into developers. Whatever changes you would make to the way we are operating, don't take this advantage away.

This is not to say I am complacent about the current state of the art here. I, too, would like to spend less time ferreting out places people have hidden files in the file system. I, too, would like to be able to tell people "just stick with these packages, and you will have no trouble." I, too, would like to spend less memory on remembering tricks which surmount obscure problems.

What I'm trying to convey is not that your goal is impossible, or not worthwhile, but that how you get there is every bit as important as where you are going. If you want to clarify the structure of the Puppy filesystem, you will have to make your case, even provide examples. If you convince enough people, the changes will become part of Puppy. If you want particular libraries, likewise, you will have to make a particular case for each.

Avoiding the hard work and tough decisions doesn't result in a lean minidistribution, it results in bloat that swallows resources. Fitting the minimum together to give many people most of what they want is a serious intellectual challenge, and a great deal of work.

This disorganized bunch has gone a lot farther than I would have predicted years ago. Whatever they are doing right, I don't want to destroy the basis for this accomplishment. Thus, my challenge to find a distributed method of harnessing all the wasted effort and unsatisfied requests seen on this forum. Finding this could be more important than any particular piece of software.

I'm afraid I've gone off again, my original intent was to make some pertinent observations on the construction and growth of program libraries. That will have to wait for another opportunity. However, rereading what I've written, I think it was worth saying. Let it stand.

[106498]

Well then, I've gone ahead and created a section on the wiki for links to packages.
http://murga-linux.com/puppy/viewtopic.php?t=52527

[nooby]

The reason it's hard to uninstall things is that the sfs file is read-only. To actually delete stuff, you have to unpack it, delete the files, then repack it - which you cannot do on a running system. You're better off starting with a barebones system, and adding stuff from there. There was a PetBeGone program and a remastering program called Remax for 4.2 and possibly earlier versions, that would allow you to remaster smaller, but no has updated it yet to work with 4.3. However, there is this tool that will get the job done manually:http://www.murga-linux.com/puppy/viewtopic.php?t=47469

With a full install, deleting stuff is no problem; It's knowing what to delete that presents an issue. I think the only way to know for sure is to download the package in question, see what files are in it, then delete by hand. With a full install, I think you could just install it, then uninstall it, and it will be gone.

The best option is to build your own Puppy with Woof (or older versions have Puppy Unleashed). Then you can specify exactly what you want in it from the beginning. I found the Woof gui to be rather confusing still, but it will improve as Barry works on it.

If I have to install from the command line (usually because I messed up X somehow), I generally unpack the pet and install by hand. It would be trivial to modify the petget command to install/uninstall pets without X. If someone mentions it to Technosaurus, he'd probably do that for 4.4.

--
I have not found that Puppy has a particularly haphazard filesystem - at least not more than Unix in general. Perhaps you could provide an example, and a suggested guideline.

trying to repair a post with a failing link by Jemimah, now it works

[sunburnt]

Squash files are almost devoid of package management problems ( or can be...).
They can be unioned. Or simply mounted and used... If they are setup to do it.

But there seems to be so little use of them. I see them as a better app. package.

They don`t need file tracking for uninstalling, don`t corrupt easily or get viruses.
And they can have dependencies included or be statically compiled.

[Lobster]

All about SFS
http://puppylinux.org/wikka/Squashfs