Saluki, Puppy Remastered

Message

technosaurus · #301 Post by **technosaurus** » Wed 24 Nov 2010, 20:32

I don't want to get _too_ far out in the weeds, but as long as gtk apps are linked with --as-needed and -lgtk-x11-2.0 (without explicitly linking its direct dependencies), the linker does a good job of resolving symbols. Most distros do some version of this even though the various autotools make it somewhat difficult. (harfbuzz in pango would be an example of something that _might_ break if all symbols are resolved at compile time and there are version mismatches)

In other words if you just use the auto*... and pkgconfig defaults then some libraries will be "NEEDED" unnecessarily as demonstrated by

Code: Select all

objdump -x <program>

Presumably this would be for static compilation, but then they fail in the other direction (by missing some dependencies on a static compile).

If you instead tell the linker to just link to gtk and let the dynamic linker load its dependencies on the fly, there is typically no problem and you counterintuitively end up with faster load times (unless you plan to recompile binaries everytime a single library changes)... and since you are worried about mixing stuff from other distros, I'd say chances are good that things will change regularly.

Now that everyone is thoroughly confused by my admittedly unintelligible rambling, I am headed home for Thanksgiving for 4 days.

big_bass · #302 Post by **big_bass** » Mon 29 Nov 2010, 18:02

I'm not trying to start something, I just want to see puppy stay at its objectives from series 1-4. Keep a small distro and a small memory/cpu footprint. I will help with packages etc, as long as I have a basic compiling environment.
ttuuxxx

this is in line with personal goals of updating glibc ,compiler and kernel and all packages without "woof" (if the current puppy devs use woof I dont blame them but they wont learn about really making a linux distro that way just running a few scripts and sorting out a few needed packages and it dosest prove they could build anything without the help of automated scripts hard but true ) then there is a pre woof step all the binaries that were compiled by T2 before they get into woof I dont see anyone addressing that issue when T2 packages will need another upgrade in the future
or just being able to do that step

maybe I am crazy after all I could just do an another update of TXZ but the future apps will need an updated glibc

I started the work of splitting packages for a test build this is not a rush job
I dont care how long it takes but I do care about doing it right

I'm not trying to start something either linux keeps improving either you keep up with it or you dont depends what you want to be doing in the next few years so far Im still having fun

another main goal is removing all the smoke and mirrors so in the end
myself and others will learn something that will be more valuable than just a version number how to survive in the real linux world

Joe

technosaurus · #303 Post by **technosaurus** » Mon 29 Nov 2010, 19:12

big_bass wrote:maybe I am crazy after all I could just do an another update of TXZ but the future apps will need an updated glibc I started the work of splitting packages for a test build this is not a rush job
I dont care how long it takes but I do care about doing it right
... Joe

I have been using glibc-2.12.1 with a -Os patch (and a couple sed scripts to force the issue) that I derived from the commit that broke -Os, but have just been using the default values for glibc and kernel version compatibility. Should these be set to an early version to keep better compatibility with existing binaries or disabled altogether for the smallest, fastest code. (Note that including earlier versions _ADDS_ workaround code => larger,slower)

btw I prefer busybox tools and simple slackware style packages (if only busybox had squashfstools I'd be set)

... to download a list of user selected packages (using short options, but busybox wget doesn't have -B or -i options)
with wget-FULL this could be
wget -c -t 0 -B $MIRROR -i packages_selected.txt

but with busybox wget:
for package in `cat packages_selected.txt`; do wget -c $MIRROR/$package; done

The big difference is that the busybox code will require much less modification if you need to add mirrors, packages,chksum validation etc... and it works with wget-FULL as well.

but it is not always the case that busybox versions requiere the extra code
... to install a .txz, busybox will autodetect the compression type now:
tar -xf /path/to/package.txz -C /
#works for tar.gz tar.bz tar.xz tar.Z tar.lzma (regardless of file extension)
#thus saving a nest of case statements if you support multiple types

The simpler the better. I try to avoid optimization that comes at the expense of simplicity if it can be avoided.

The more complexity that gets added, the harder it is to maintain/fix (such as supporting 10+ different install methods that you don't personally use ... or 100 languages that you don't speak, or 1000s of hardware that you don't have)

jemimah · #304 Post by **jemimah** » Mon 29 Nov 2010, 20:56

I say we go for fast and small and not worry about binary compatibility. We've got enough people interested in compiling packages, I don't think it'll be a huge problem.

I also strongly agree with "the simpler, the better".

Iguleder · #305 Post by **Iguleder** » Wed 01 Dec 2010, 09:31

jemimah wrote:I say we go for fast and small and not worry about binary compatibility.

You're my hero

Puppy is a top-ten distro, it doesn't need binary compatibility. It's a nice bonus feature, though.

big_bass · #306 Post by **big_bass** » Thu 02 Dec 2010, 00:35

Puppy is a top-ten distro, it doesn't need binary compatibility. It's a nice bonus feature, though.

reading your link reference from here
http://murga-linux.com/puppy/viewtopic.php?p=471825

It consist of around 90% Debian package, in contrast with other Woof-built puppies. Just for comparison - Lucid Puppy 5.1 consists of around 65% Ubuntu packages. This means its development more is much more future-proof.

hmmm I am some what confussed by these statements use 90% debiain packages and 10 % other packages
then decide it was a nice bonus feature to have binary compatibilty you didnt plan on ?

was binary compatibily an accident in the design process that some how became a nice bonus ?

I agree in what you did and said the second quote
I disagree in what you said in the first quote about not needing binary compatibility

Joe

Aitch · #307 Post by **Aitch** » Thu 02 Dec 2010, 02:44

Techno...

http://lists.busybox.net/pipermail/buil ... 35459.html

http://old.nabble.com/-git-commit-maste ... #a29759963

Dev: Peter Korsgaard

Any use?

Failing that, maybe contact dev: Philip Lougher for SFS

http://sourceforge.net/projects/squashfs/

http://sourceforge.net/tracker/?group_i ... tid=505344

Also, this..

http://lwn.net/Articles/386375/

or this?

http://imrannazar.com/Booting-Linux-from-Flash

TCL seem to be looking at the same path

http://tinycorelinux.com/forum/index.php?topic=6931.0

Let me know if anything is useful...I'm searching blind

Maybe time for some magic?

http://www.sourcemage.org/SourceMage_Wiki

Aitch

big_bass · #308 Post by **big_bass** » Fri 03 Dec 2010, 00:52

btw I prefer busybox tools and simple slackware style packages

having slackware package format just makes a "standard"
any linux adminstator would understand

unraveling pets is even a job for us around here that do understand pets for all the different versions of puppy and how many more times could the format change ?

there is a lot of room to strip packages down and separate them too
to build a custom devx

busy box can be customized and features added no problem
only requirerment their is stability being the number one
if it can be added and no loss to stabilty go for it

saying that glibc is compatible with a major distro in no way confines you
any packages could be complied that were needed

as far as cutting down the kernel that depends on what "extra" could be cut out of the kernel simply a lite kernel a generic kernel and a full kernel
all being the same kernel version and install them as packages

for those that have problems with not having enough ram the lite kernel
or the generic kernel dosent have the needed drivers you could just install
the full kernel without rebuilding everything again

Joe

#309 Post by **ttuuxxx** » Fri 03 Dec 2010, 01:40

I agree with big_bass on the GlibC version matching with a mainstream Linux 100%, As long as we match the GlibC version then user can expand in the future, Look at series 3 when they made k3b work using slackware packages, If there is a will there is a way. But not using the same glibC is just plain dumb. Why take the fun out of it? We aren't talking about the whole backend just the GlibC. Gtk matched version would be nice but really that important. I do know one thing. The latest Gtk that isn't Gtk3 would have to be used, because many of the latest gnome apps, require the latest gtk2 and you can't downgrade the version numbers, I think they added new features in the final gtk2 that isn't found in earlier versions and you get compiling errors when you downgrade version numbers, The latest puppy 5.2 has this issue also, Its gtk2 backend can't compile many of the latest gnome apps, I had to use one or two previous versions before it would compile.
So basically a large distro matching Glibc and latest Gtk2 would give us the largest room to grow.
ttuuxxx

Lobster · #310 Post by **Lobster** » Sat 04 Dec 2010, 10:29

Programming and system development is about focus.
For a moment let us think wide (a game I play
with my imaginary psychiatric team)

In the future Puppy will be running
on mass market tablet devices
Designing for this eventuality is not easy
as the ARM powered devices are still being
developed.

There are several directions from which this is possible
1. with high debian compatibility in post Lucid 5.2
2. with an intent at this stage of Saluki
3. with the slackware compatibility suggested by Bigbass

We can not develop for what is not yet there
but a puppy nook or similar?

Me want

big_bass · #311 Post by **big_bass** » Sun 05 Dec 2010, 20:50

hey lobster

There are several directions from which this is possible
1. with high debian compatibility in post Lucid 5.2
2. with an intent at this stage of Saluki
3. with the slackware compatibility suggested by Bigbass

really what is needed we are doing
and that is trying to find some common ground
this is a process where conflicts do occur

I dont dislike someone for disagreeing with me
or having another point of view

just be clear
make your point and why you think that it is a better option

at least I know where they stand on an issue

but to get any real support or a team going you will have
differences of opinions

the object is to find out on what areas people do agree to
to a step forward

basically its like ok up to here we are working on the same goal
lets try and take another step

you would be surprised to find
some ideas are shared between us all
the hard part is finding out what they are

and communicating them correctly

Joe

technosaurus · #312 Post by **technosaurus** » Wed 08 Dec 2010, 21:59

so I built the gtk code base and started compiling the "core" apps...

First app = Rox

I thought I did something wrong because Rox was misbehaving even with all available patches, so I started over and tested in quirky/wary - same problems with all versions >2.16.6 (the higher the version the more problems)

Can we all decide to kill Rox as the default and transition to the more actively developed PCManFM in the base?

jemimah · #313 Post by **jemimah** » Wed 08 Dec 2010, 22:17

I definitely think we should try PCManFM as the default.

gcmartin · #314 Post by **gcmartin** » Wed 08 Dec 2010, 22:29

jemimah wrote:I definitely think we should try PCManFM as the default.

2nd that. Leave ROX as an option for those who want to download it. PC is so far ahead of ROX. If I understand it, it also has simple interface to have installing system apps to extend drop-downs accordingly.

Just my observation.

Aitch · #315 Post by **Aitch** » Thu 09 Dec 2010, 15:07

A possible option to PCmanFM, maybe because I like tree view/Explorer type view

sorry about the size

http://roland65.free.fr/xfe/

or Double Commander?

http://doublecmd.sourceforge.net/

Aitch

technosaurus · #316 Post by **technosaurus** » Thu 09 Dec 2010, 21:30

nothing against xfe, I like it, but it is not a viable replacement option
1) xfe requires fox libs (loses on size)
2) doesn't handle desktop icons (loses on resource usage - would need an icon manager)

jemimah · #317 Post by **jemimah** » Thu 09 Dec 2010, 21:46

Also there's something to be said for having as many applications as possible with the native GTK look and feel.

Having FOX though does get you Goggles Music Manager... which as far as I know is the only lightweight music player that can handle huge libraries, mp4/aac tags, cover art, and has a mixer. Probably too big for the base, but IMHO, totally worth it.

technosaurus · #318 Post by **technosaurus** » Fri 10 Dec 2010, 00:14

#319 Post by **ttuuxxx** » Fri 10 Dec 2010, 00:23

technosaurus wrote:so I built the gtk code base and started compiling the "core" apps...

First app = Rox

I thought I did something wrong because Rox was misbehaving even with all available patches, so I started over and tested in quirky/wary - same problems with all versions >2.16.6 (the higher the version the more problems)

Can we all decide to kill Rox as the default and transition to the more actively developed PCManFM in the base?

for the first release would ok, Then I'll look at rox and see what I can do to fix it, what issues does it have? Usually Rox is very stable. Simple to use, and the best window file manager/pinboard around by size. as long as PCManFM is a temp fix, I'll be a part of this release, if its a long term replacement for Rox then I can't see myself sticking around. But Like I said I'll try fix the issues first. Also gtk 2.16.1 has been default in 2.14X for about a year and rox is very stable with that gtk version, So if there is a gtk issue, then it would be easier to read the gtk updates from 2.16.1 to 2.16.6 and figure out the changes where it gets broken. That's where I would start.
ttuuxxx

jemimah · #320 Post by **jemimah** » Mon 13 Dec 2010, 06:05

Technosaurus, if you're still playing with Gtk, we figured out that glib can be modified to look for drives under /mnt instead of /media. If you make the change, then your mounted drives show up in the right pane of Gtk file chooser dialogs. I think this is a huge usability enhancement. I will post a patch if you're interested.

--

Also, I figured out that glib 2.23.1 is the last version of glib where my SVG tray applets work. However I'm not even close to figuring out why yet. GIO lazy module loading was introduced in 2.23.2 - that might be the culprit, but I can see that the svg module is loaded when I run strace on it. So I'm baffled.

Maybe porting them to a newer version of Vala would solve it.

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

Saluki, Puppy Remastered

PCManFM