Saluki, Puppy Remastered

Message

#76 Post by **ttuuxxx** » Sat 11 Sep 2010, 15:28

fine then, If you add up the number of post from the past 3 users and multiply it by 3 they would have less number of post then I have.
Really I guess it boils down to who coordinates puppy 6.
Lets have a poll, Ummmm if you want track records, puppy 5 group effort packages is http://distro.ibiblio.org/pub/linux/dis ... ges-lucid/
and well my personal packages for 2.14X .14x is
http://www.wisdom-seekers.com/puppy214x.html
Really I'm done with it.
ttuuxxx

clarf · #77 Post by **clarf** » Sat 11 Sep 2010, 15:46

I feel culpable to start this debate, but I agree with techo the time to decide the right approach is in the planning phase.

Many thanks for share your knowledge, I fully take you words (you have the experience and knowledge about it). Then, i386 is still a valid compilation option that reduce effectively package size in non performance critical applications and brings support to non conventional (Intel, ADM) processors (I remember some thread in this forum talking about intel process patents that are expiring right now.)

technosaurus, about compile specific libraries and applications on top that could benefit from optimizations, just arise the packaging problems of Puppy, there´s no one central distribution place and not even a standard way to do compile or reference dependencies, not even a globalized rule to say what specific libraries should be compiled for a specific architecture. Soon or late we´ll have to set some standards here.

ttuuxxx VLC compilation seems to run faster in and old PC (the main target of Puppy distibution), but I think that you will get the opposed results in a new machine with all the optimization enabled. I´ll like to make the same test in a newer PC with a package compiled for and advanced architecture, I think in that case VLC will work even faster (surely not too much) than the i386 compilation (obviously compared with the i386 compilation in the same new computer).

I agree ttuuxxx, we don´t have to forget Puppy essential. But, sadly recent Puppy version had doubled the machine requirements lately, as the memory consumption and size has been increased to, so the return to life to old systems is something that had been slowly passed apart. And the other thing is the competition with newer Linux Distributions, in the past Puppy was in the same level that DSL, at that time I tested Puppy and I get involved, now the fight is against bigger rivals. I steel loves to play with my ancient hardware but I feel comfortable using old Puppy versions on them, with the same old applications.

I also agree about common normal Puppy users don´t need the kernel bloat to support more than one core (Although I think the size difference is small). In this case I believe it depends from the final user needs, if he need additional horsepower for heavy task like video post processing or like in my case mount big Relation DatabasE or Enterpise Applications, the user surely will choose another distribution or just a Puppie adjusted for that, Fatdog64 comes to my mind. But young people or computer starters with newer hardware needs support too.

We can´t just maintain two Official branches?.

big_bass · #78 Post by **big_bass** » Sat 11 Sep 2010, 15:54

Hey Jeff (ttuuxxx)

If puppy 6 goes beyond i486, well that will make 2 versions I won't participate in

Jeff there are a few options to make everyone feel comfortable
and give you more flexibility to chose what is best for you

here's an example of how
sharing work on different bases will work
anything can be shared if a build script is made and even better with patches

this is just a small a snip of how a slackware build script allows you more freedom to share work

Code: Select all

if [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
fi

set -e

just by having a build script it can be easily reproduced
on any base. Patches could be added and build scripts could be fined tuned for smaller packages by having the special config opitions that we need
for a light distro

so what I am suggesting here is taking a more professional
solution to package builds by starting out with build scripts

they are easy to edit and keep updated

Joe

Iguleder · #79 Post by **Iguleder** » Sat 11 Sep 2010, 16:02

ttuuxxx wrote:fine then, If you add up the number of post from the past 3 users and multiply it by 3 they would have less number of post then I have.
Really I guess it boils down to who coordinates puppy 6.

You could coordinate it even without a single post in this topic, ttuuxxx. But don't forget you can't do this on your own. If you want to be a leader, you need people to follow you and trust you.

One-man efforts die quickly and quietly. The latter also applies to selfish and egocentric people.

I know it doesn't matter much, I won't follow you.

clarf wrote:We can´t just maintain two Official branches?.

Both a question mark and a full stop, that's a sign from God probably

clarf is right, why can't we have two branches? Why is it so bad to express some pulralism and democracy within the community?

Umm ... what about three branches (normal, retro, and ttuuxxx)?

linuxcbon · #80 Post by **linuxcbon** » Sat 11 Sep 2010, 18:58

I think i386 is good enough.
See http://linuxreviews.org/howtos/compiling/safe-cflags/

Code: Select all

CHOST="i386-pc-linux-gnu"
CFLAGS="-march=i386 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i386 -O3 -pipe -fomit-frame-pointer"

big_bass · #81 Post by **big_bass** » Sat 11 Sep 2010, 19:24

a mini how to build using scripts

the script keeps things transparent to everyone
and even if one was unsure about all the code it will produce a correct package

one easy example

------------------------------------------------------------------------
#slackbuild home page
http://slackbuilds.org/repository/13.1/office/leafpad/

#download slackbuild scripts (no sources)

Code: Select all

wget http://savannah.nongnu.org/download/leafpad/leafpad-0.8.17.tar.gz

# my downloads go in a folder called "Downloads" not very original

# you edit this if you use another folder

# open a terminal or cd into the folder

Code: Select all

cd /root/Downloads/leafpad/leafpad/

#download official sources

Code: Select all

wget http://savannah.nongnu.org/download/leafpad/leafpad-0.8.17.tar.gz

#run the slackbuild to make the package
#now here is where you can modify the script to use your own personal config
# to build smaller packages for a lightweight distro and share your work easily

Code: Select all

./leafpad.SlackBuild

#now look in /tmp and you package is complete

#changing one line of code in the version number
# and you can easily re build leafpad when a new version is offered

this is an example how one at a time we can build the packages
light and for speed and once again if you prefer another dependency
or remove even more you have the liberty to do so

Joe

bigpup · #82 Post by **bigpup** » Sat 11 Sep 2010, 20:20

All of this talk about old and new hardware support is just going in circles. Puppy Linux already has support for old hardware and new hardware. Just look at the different versions of Puppy you can download and use.
The big problem is, for someone new to Puppy, easily figuring out what version will work best on the computer they have.
human nature always wants the newest version of something. If they see Puppy Linux 6.0 they want that one, not Puppy 4.3.1.
Barry's idea with Puppy 4.3.1 normal and Puppy 4.3.1 Special puppies was a start, but it was never clear what the Special puppies where designed for. Just the hint older equipment.
For human nature:
Puppy 6.0
Puppy 6.0 Retro
But be specific about what hardware each supports.

Barry's Wary 0.7 mix-n-match idea?
Pick a solid older version of Puppy and rename Puppy 6.0 retro?

#83 Post by **BÃ©Ã¨m** » Sat 11 Sep 2010, 23:26

From a simple user's point of view: let puppy be the easiest least effortless configurable linux system.

Small simple example: when ever I change some version, I have to look in my scratch book to set the time to 24 hours.
Today I saw a question of a person who wants a dark background and white letters. Tomorrow there might be another one for another combination.
It can be done by changing some line in a obscure hidden place.

Nothing for people who want to easily adapt their system.

So what did I experience so far?
f.e. the 4.40CE was on a good way. But the project stopped.
Dude is also nice, but doesn't have every thing, seems to have some problems with lucid on which I tried and isn't high on the priority list of Zigbert as far as I understand.
Tazoc has made a nice implementation in that aspect also with lighthouse.

I did feel pretty comfortable with KDE3 (did try KD4)

Another thing is to be able to install packages outside the save environment in a frugal installation. In other words have portable pet's.
Personally I did find some tricks, but not for all packages. A change from lucid xxx to lucid yyy or quirky xxx or wary xxx is pretty easy and within a few minutes I have my working environment operational. But it is beyond the scope and knowledge of the overall user.

Also I don't think the overall user lies awake to know if the system is based on puppy, debian, ubuntu, slackware, txz, i386, i486, i586, i686, he just wants to work on his machine.

Quite a challenge, no?

jemimah · #84 Post by **jemimah** » Sat 11 Sep 2010, 23:51

I think the question of whether or not Puppy will run on their hardware is actually of utmost importance to the user.

A portable pet is called an SFS file. Pet Maker Plus can convert pet to SFS.

User-friendliness depends on the packages selected. Generally the smallest package in any given category is not the nicest. Sure rxvt is a pain to configure - but there are dozens of friendly terminals with easy menus - they're just bigger. The cost of optimizing for both size and convenience is probably somewhere around 20-50 extra MB. IMO usability is worth it - but you lose bragging rights for the smallest ISO.

gcmartin · #85 Post by **gcmartin** » Sun 12 Sep 2010, 00:07

There are a LOT of good comments in this Thread. So, I will NOT depart from much of whats already been thrown against the all.

But, I have many customers and over the past year, I have been eagerly following Puppy as an alternative desktop to MS in SMBs and Enterprises. I hope you will see what I share for you, here.

Puppy seems to be attempting to move in 2 different directions at ONCE.

Adding needed functionality for the user community
Trying to run in an extremely small footprint across ALL hardware platforms

Having 40 years in this business, its a noble goal, but the reality is that this is PHYSICALLY IMPOSSIBLE.

So, whether anyone likes it or not, tough decisions have to be made considering the amount of resources, here, that's needed to insure Puppy's future success.

I am not endorsing a split in the community because each and everyone is needed if Puppy is going to continue to be competitive in the Computer world (remember, it not just a LInux world...its a computer world). And, even today, Puppy is still lacking in needed services that would make it capable of standing up against a simple MS platform as a replacement on a network of other PCs.

This is how I see directional options in this thread. I see that one direction is going to cover thousands of machines as it marches into the future, while the other will cover only hundreds of machines. As a community of developers and contributors, you are needed to band together to decide which of the communities you want Puppy to address and how to best meet the needs of users who will look at Puppy.

Its tough to address both, but it may be needed to identify what is best for the overall Linux user community. If the Puppy community does not have the resources to address both, then MAYBE an option is to stabilize Puppy for one on the community and concentrate resources to move Puppy in a direction so that it remains competitve and adds functionality that is needed.

I know that many feel that this thread is addressing this, but I thought this post would be "a break" so that each thinks about what's best overall; and an attempt to get most of you to work together, even though you may not agree. Overall all development skills are needed to move Puppy forward. Let's move Puppy forward. And not forget the past, where possible. Maybe even assign resources who want to work ONLY on the past.

LOLuck!

scsijon · #86 Post by **scsijon** » Sun 12 Sep 2010, 02:35

Iguleder wrote:
clarf wrote:We can´t just maintain two Official branches?.
clarf is right, why can't we have two branches? Why is it so bad to express some pulralism and democracy within the community?

Umm ... what about three branches (normal, retro, and ttuuxxx)?

Settle down folks (please).

Reading this and other posts (not just puppy) relating to start of version steps, I was thinking about three branches, however I was considering something like this.

-------------------
Hot: Designed and compiled for the latest and greatest hardware.
It has a warning on it that it may not work with a users machine.
Considered to be "cutting-edge".

Standard: Designed and compiled to work with most hardware.
Where do we start and finish though?

Retro: Designed and compiled to work with older hardware.
May work with the latest application package, but that would
be the packages problem, not the o.s.
A warning that not all packages will run on this version or an
earlier version may be required.
------------------------

From further thought: ?do we need to add a fourth notebook version. They do seem to be an opening horizon now they are available at a decent price.

My only worries would be if it means there would need be a separate version of each application for each branch. ?Is there the ability to add within a .pet to deal with the different versions and library sets that would ocurr or be needed.

Just maybe, it's also "puppytime" to consider setting up a few people/groups to be "puppy application co-ordinators". Not to stop or control builds, but to help and direct assistance with an application.

I'm also wondering if it's time to separate the /root from the (what I call the) "apps plus" savefile and give it one of it's own. Most users seem to keep their work here (usual disclamer). It would mean that you should be able to "take your work with you". Only initial requirement I can see may be the need to have the ppm/quickpet files with it so it can "order" a download of a needed application. Alternately all downloaded apps in pet format could be stored under something like a /root/.ppm/packages and installed "on demand" (when a user wants a file), and yes I do realize there could be version problems to overcome.

a thought or two to consider as we work towards what really is a major puppy step!

regards
scsijon

big_bass · #87 Post by **big_bass** » Sun 12 Sep 2010, 04:46

We can´t just maintain two Official branches?.

at least for me I was very clear about not being concerned about any official status

the goal I am looking for is bigger than one person
could ever do

what has always been is people select something already made then fine tune it or modify it to their needs

I was hoping for a joining of creative people to form what is best from the start

a version built by the community from scratch (and it not being a community edition either)
not a take whatever the latest official version is and the fine tune it
until another official version bumps it off and gets unsupported

I m looking for a something bigger than a version
a way to make it and keep it updated
independent of any official build

teams are people working together to achieve more than they could do alone
and the outcome is better because it takes many different talents to come together

many pieces are required which is the piece you have to offer?

Joe

#88 Post by **ttuuxxx** » Sun 12 Sep 2010, 05:07

big_bass wrote: a version built by the community from scratch (and it not being a community edition either)
Joe

That's what I mentioned for puppy 6 about 4 months back, I would be willing to lend a hand, I also would like to see the kernel patched for vortex86mx so we could support the Surfboard also.
There is already a patched kernel for the surfboard located at http://www.deviceonchip.com/index.php?o ... &Itemid=85
maybe it could be used as an example.
ttuuxxx

Stripe · #89 Post by **Stripe** » Sun 12 Sep 2010, 12:09

Hi all

Just a quick couple of lines from a newbie to puppy,

What brought me to puppy? Windows 7 sending personal information god knows where.

Why puppy? After looking at all the linux offerings, ease of use, speed, easy to set up and does what I want it to do (lucid 501)

What am I using as a main distro now? Fluppy, why? have just built a brand new 2 core machine and having sound problems with the woof built pups so have changed to something that works for me and my hardware (including my old 800mhz 256 ram spare box).

What would I look for in a new puppy?
1. works with as many machines as possible
2. Up to date software compiled specialy for that puppy
3. well written to minimise resource useage (ram cpu etc)
4. Fun and easy to use

What would not worry me.
1 kernel version (as long as it works)
2 size (within reason) (I think the last slackware version I downloaded was about 4 Gb)
3 what the software was written for (ubuntu, slackware etc)

Hope this helps
Stripe

Dragynn · #90 Post by **Dragynn** » Sun 12 Sep 2010, 18:03

Chiming in too, as a newb to Puppy and Linux, but not unfamiliar with the genre.

JMHO, but I wonder if it wouldn't be possible to include a couple of different basic versions on an ISO, and have the system probe the hardware (pretty much as it does now) and select the version best suited to the hardware of the machine in question?

Secondly, I do very much believe that it's possible to keep the actual size advantage (small) AND accommodate newer tech without growing too large and complex, simply by loading less programs to start with (shotgun effect in some of the distros i've tried), and using some of the space saved to utilize better quality programs, quality, not quantity. With the overall goal of simply making this boot up swiftly and cleanly and have basic functionality from the get-go on any machine for any level of user-experience. After that, people can be responsible for their own additions, and thus also, any damage that occurs due to their own (mis)use.

Make it boot on anything.
Give it a decent desktop/gui.
A file browser and simple shortcuts and menus to store info, documents, music.
Make sure it can connect to the internet via wired or wireless if the machine has the hardware to do so.
Give it a way to play/open/burn/rip media.
Give it a basic text editor, a basic calculator.
Add a firewall, anti-virus. Add a simple Ccleaner-type utility, one that only gives a few safe options (bleach bit with some of the choices omitted should work.
And lastly, a simple way to add software, the quickpet in 5.10 works perfectly and brilliantly for me.

And that's it, let the end-user "customize" it themselves. A totally better mousetrap, an OS that will work on anything, anytime, anyplace and never fails to boot and give instantaneous complete basic functionality.

The thing to remember, is that this is the country that made anecdotes, about all the trouble millions of people had in programming their VCR's, a cultural meme.

K.I.S.S.

clarf · #91 Post by **clarf** » Sun 12 Sep 2010, 22:25

The Puppy 6 name really confused me, but As big_bass said if we remove the official status from our head we could have the freedom to develop something really interesting. I would like to see a Puppy from the scratch totally independent from other distro.

Something new, No just Puppy with latest software and latest kernel. Although I don´t fully share the Igulender idea to remove everything old, if we want to do the things right We have to move one step at a time (I also feel Puppy should move to a i686 architecture when Barry want to).

I don´t see Puppy (official or not) as a bloated distro of 4 GB, We are always trying to keep it small and fast, this is the Puppy essence as ttuuxxx stated, the problem is unifying that dispersed work.

Why everything must be white or black, there are no space to gray thinking?. I mean,

- We could partially offer support to old hardware making available a version with an older kernel (I don´t talk about 4 or 5 versions either), although it is important (as many people already stated here) to delimit the oldest or additional hardware to support. As techo said maintain the core base at a lower architecture, at the same time having availability to add specific applications and libraries optimized for those who need it.

- We can also make some steps further changing the Package system. big_bass system seems something that I wanted from long time ago for Puppy, the ability to list and remove all the pre-installed packages (something beyond "pet be gone"). And a standard automated system to build the entire system with fine tuned scripts (beyond Puppy from the scratch or even Woof) seems a must have to unify/share individual work and regain some order in Puppy Community.

This should be the opportunity to develop a way to work in Puppy not only build a new version. Even if we work in more than one cutting-edge or legacy branch, in a specific oriented architecture, even a desktop or server version, there should be a way/model to recycle ideas and share this work.

clarf

technosaurus · #92 Post by **technosaurus** » Sun 12 Sep 2010, 23:56

Why not Ki-tty?
Then to get the version number in init the command would be:
KITTYVERSION=`cat /KITTYVERSION`

j/k

actually I have been going through the init script and there is potential for a lot of speedups:

1. using the full path REALLY slows down processing, since busybox can call these internally
(/usr/)
2. searching for puppy files - make the locations part of the install script... and now naming is irrelevant
(kernel /pupngo/vmlinuz ... PUPSFS=sda1/puppy-6.0.0/lobster.sfs SAVESFS=sda1/puppy-6.0.0/lobster.4fs ZDRVSFS=sda1/puppy-6.0.0/cutmodules.sfs ....)
3. Many probes could be done as part of the construction of init.
(export PUPPYVERSION=, KERNELVERSION=,....)

other possibilities:
4. don't switchroot (see tinycore for example init)
5. delay X related things till after init like updating gtkiconcache etc...
(jwm has a Startup block that will do this as well as starting things like Rox-filer - see PupN'Go thread)
6. if someone could backport squasfs4 to the 2.6.16.62 kernel, that would put us in good shape for older computers

scsijon · #93 Post by **scsijon** » Mon 13 Sep 2010, 01:55

technosaurus wrote:Why not Ki-tty?
Then to get the version number in init the command would be:
KITTYVERSION=`cat /KITTYVERSION`

j/k

shouldn't that be kitten

I get complaints, when I show puppy to possibly new users, of too many option applications which are not used or wanted (yes I know delete the icons).

One of the things i've been pushing is the idea of having the least possible applications in the basic puppy. Desktop, System, Setup, Utility, Network and Help should be as complete as possible and "work out of the box", but the rest should be cutdown to the bare minimum. I believe a cutdown puppy with most applications as pets would be a winner in converting win users across.

Mind you i'd also like to see as part of the early install process step (before download), a five or so line explaination of what the package does with an output/cancel button available at this point.

regards
scsijon

ps I noticed wine was up to 1.3.1 (now 1.3.2) yet ppm still shows we are using 1.1.43, green_dome's thread is http://www.murga-linux.com/puppy/viewtopic.php?p=447856, there is a note on p6 from me and another note in reply by lessloco who is apparently using it with 5.1.

big_bass · #94 Post by **big_bass** » Tue 14 Sep 2010, 16:49

simply

you cant microwave a distro in a few days

if you dont take the steps to

build a kernel and add in the modules *manually

rebuild the init.gz *manually

sort out what packages to use *manually

rebuild the network modules GUI *manually

compile extra modules *manually

make a compiler with packages

have some logical package management
hand written to install remove check dependencies and build the
OS with *coding this yourself

being able to compile packages from source *manually

having a plan to logically piece everything back together and have it boot

*then it would be better to just woof build something /remaster and keep up with the jones and forget about trying to really take building from scratch seriously
or ever learning how to

--I still think someone that is serious about doing it will take at least the steps
I listed above your actions will dictate the direction you took

Joe

jpeps · #95 Post by **jpeps** » Tue 14 Sep 2010, 19:38

scsijon wrote:
I get complaints, when I show puppy to possibly new users, of too many option applications which are not used or wanted (yes I know delete the icons).

One of the things i've been pushing is the idea of having the least possible applications in the basic puppy. Desktop, System, Setup, Utility, Network and Help should be as complete as possible and "work out of the box", but the rest should be cutdown to the bare minimum. I believe a cutdown puppy with most applications as pets would be a winner in converting win users across.

I'd have to disagree...Puppy is already small, especially considering the space available on most computers. A stripped down version would require constant installation and updating of libs, etc., which is beyond what non-geeks will tolerate. Installing a stripped down version, other than for some specific purpose like repairing windows, etc., is for those who enjoy customizing....and I'm talking easily 50 or 60 add-on installs for basic usage (all of which require updating, tracking deps, etc.)....quickly becomes an unnecessary nightmare!

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

Saluki, Puppy Remastered

What should Puppy do as it matures