Saluki, Puppy Remastered

[big_bass]

Iguleder

I just noticed today that you have an interest in package management
you wrote code for a thingy manager interesting

I spent a lot of time writing a GUI front end to slackwares pkgtools
and it is 100% compatible on the official slackware or on TXZ pup
called slaxer_pkg_tools2.2
http://pastebin.com/kYUcMhSx


Joe

[jemimah]

How old of a computer is it reasonable to try to support? At what point do we give up on older hardware?

[Aitch]

LOL Good call, jemimah

However it's not the failure rate on a lot of my old hardware that bothers me....it's the electricity bill!

Old scsi server boxes run wonderfully but you can almost cook on 'em, they need loadsa room, and damn, they're noisy

Anyone know what happened to Ted dog and his T2 cross compile efforts?

Anyone get a VIA 8505/Eken M001 iPad clone running puppy?....Android's running away with it, atm

They'd be a bit more economical, I suppose....and they're less than $100

http://www.alibaba.com/trade/search?Sea ... t_en&fsb=y

Aitch

[technosaurus]

@bigbass
I compiled busybox to include the config options. Just run

Code: Select all

bbconfig >my_dot_config

The patch to add minimp3 is already attached in my previous post (and I posted the patch to the busybox mail list)

I understand your point about people using full media players, but I think that at least during development, it is a good idea to have a method of testing that all your piece/parts work including sound, especially if we are going to have a minimal base install. (I do have a separate build of minimp3 though and it is only ~31kb) It would suck to be weeks/months into development and figure out that sound was broken. I'm not 100% sure, but I think that the busybox beep applet uses the pc speaker, so it wouldn't be a good test.

Re:pkgtools - do you have a good reference for putting the build info in the proper format ... and does it work with Amigo's src2pkg?

[dejan555]

Puppy from scratch sounds good. I support that.
If you go that way I will surely join testing.

[big_bass]

@bigbass
I compiled busybox to include the config options. Just run
Code:
bbconfig >my_dot_config

Thanks for the quick response is there another way to run that code you posted without installing the new busybox ?

if not could you pastebin it please when you have the time ?

Re:pkgtools - do you have a good reference for putting the build info in the proper format ... and does it work with Amigo's src2pkg?

any package slackware compatible will work to build with tgz ,txz ,tlz ,tbz

there are also two dragNdrop scipts to make a slack-desc automatically and
and to make TXZ or tgz packages

and yes of course I am compatible with amigo's src2pkg I have had interest in his tools since puppy linux version 3.01 and was the first to get src2pkg running on puppy of course thanks to his help and advice it has become a backbone
to building packages there is also a GUI config tool I wrote for it
its isnt required its just handy add on to have when doing many complies

GUI for the configuration of packages for src2pkg
http://www.murga-linux.com/puppy/viewto ... h&id=26243

original post
http://www.murga-linux.com/puppy/viewto ... 90&t=51197

Joe

[technosaurus]

@BB re:bb - sure... I'll gzip the .config and post it when I get home this evening (it is basically an allyesconfig without pam, selinux, rfkill or debugging and includes the "full" versions of modutils ... basically setup to include as many desktop tool replacements as possible not for the initrd)

[raffy]

To the question "how old (hardware to support)", one may say "Pentium III", but the challenge is more of supporting alternative low-power configurations. In this regard, we have the xcore86 (edubook, which Barry said is OK with the latest kernel in Wary 070), also the VIA Unichrome and AMD Geode GX/LX, among others.

[technosaurus]

To the question "how old (hardware to support)", one may say "Pentium III", but the challenge is more of supporting alternative low-power configurations. In this regard, we have the xcore86 (edubook, which Barry said is OK with the latest kernel in Wary 070), also the VIA Unichrome and AMD Geode GX/LX, among others.

All of those should work with -march=586 - the only 486 platforms readily available and fast enough to comfortable run are the vortex86 and some of those don't even work with the standard puppy 486 build (vortex86sx don't have a fpu - similar to the 486sx) ... the -march=i486

Edit - Busybox patches added + an additional patch that will alias waitmax to busybox's timeout applet... there are a couple of differences though

• # timeout --help
  BusyBox v1.15.0.svn (2009-07-25 18:23:53 GMT-8) multi-call binary
  
  Usage: timeout [-t SECS] [-s SIG] PROG [ARGS]
  
  Runs PROG. Sends SIG to it if it is not gone in SECS seconds.
  Defaults: SECS: 10, SIG: TERM.
  
  # waitmax --help
  Usage: waitmax [-s SIGNUM] MAXTIME PROGRAM [ARGS...]
  
  Execute PROGRAM as a subprocess. If PROGRAM does not exit before MAXTIME
  seconds, it will be killed with SIGTERM or an alternative signal.
  
  -s, --signal SIGNUM kill with SIGNUM on timeout
  -h, --help this help
  -V, --version show version an exit

It should mean minimal rewrite to the init script... or would it be better for me to just add waitmax to busybox?
I am trying to minimize the number of binaries required in the initrd, preferably down to just busybox for faster boots. Now that I know how to add an applet, its just a matter of condensing the code into one .c file (waitmax already is) and editing about 4 other files. (I wonder if sqlite's amalgamation script could help make the process easier, or if it is sqlite specific?)

[mavrothal]

I'll gzip the .config and post it when I get home this evening (it is basically an allyesconfig without pam, selinux, rfkill or debugging and includes the "full" versions of modutils

Mobile computing devices are really expanding and rfkill would be nice to include. Also debugging would be useful. At-least at the early stages of the project.

[jemimah]

I agree about rfkill. I believe the kernel bug that plagued Barry's Acer has been fixed by 2.6.33. I build my kernels with rfkill (even Fluppy) and so far no one's complaining.

[linuxcbon]

What about removing unused users and groups in /etc/group gshadow etc .

[technosaurus]

I agree about rfkill. I believe the kernel bug that plagued Barry's Acer has been fixed by 2.6.33. I build my kernels with rfkill (even Fluppy) and so far no one's complaining.

I need to upgrade to a different kernel so that rfkill.h is available in order to make it compile.

I will add rfkill when I rebuild it in aboriginal, but for the time being I am busyboxing the other programs that are used in the initrd. So far I got:
guess_fstype working (still needs some busybox code tweaks)
fusermount condensed down to a single C file so it is pretty close
identified timeout as a replacement for waitmax

I am also considering the rest of the binaries in initrd that aren't already available in busybox (those can be replace already with some code modifications borrowed from tinycore/slitaz)

other possible busybox applets:
autologinroot
suggestions?

Note: So far I can get everything to work and compile as an applet, usually with warnings due to duplicated/differing code from busybox. Denys Vlasenko sent me some advice back to reduce the warnings (and thus code size as well) but I can't actually code in C, so it takes me a while to easter egg the correct fixes. If anyone has time to do some C it would help out a lot and your work could end up getting included upstream in busybox proper. I have set up a 4 stage process to accomplish this - kindof a busybox staging area.
Stage 1: gather all of the files that a program needs to build into one folder. such that it will build with gcc *.c -o <applet>
Stage 2: condense all of the files into a single C file (similar to the sqlite amalgamation) that will successfully compile with a simple gcc -o <applet> applet.c
Stage 3: tweak the includes section of the C file to use libbb.h and tweak about 4 *.src files in busybox to try and build it (correcting errors until it builds)
Stage 4: once an applet builds - it goes here for code formatting and fixes (use busybox functions where possible and remove unnecessary code)

I plan to do this a little different than my last tarball - rather than one large patch, I'll split them out by applet and include the <directory>/<applet>.c file and a small patch for the few modifications. This will make it easier to apply to later versions.

[clarf]

To the question "how old (hardware to support)", one may say "Pentium III", but the challenge is more of supporting alternative low-power configurations. In this regard, we have the xcore86 (edubook, which Barry said is OK with the latest kernel in Wary 070), also the VIA Unichrome and AMD Geode GX/LX, among others.
All of those should work with -march=586 - the only 486 platforms readily available and fast enough to comfortable run are the vortex86 and some of those don't even work with the standard puppy 486 build (vortex86sx don't have a fpu - similar to the 486sx) ... the -march=i486

I know ttuuxxx still compiles software with -march=i386. I don´t want to start another debate for this but I think it should avoided for future Puppy releases, the older platform to point should be 486 as minimum (and even this architecture is too old to be considered, I haven´t seen any functional/active pre-pentium system from long time ago).

It should mean minimal rewrite to the init script... or would it be better for me to just add waitmax to busybox?
I am trying to minimize the number of binaries required in the initrd, preferably down to just busybox for faster boots. Now that I know how to add an applet, its just a matter of condensing the code into one .c file (waitmax already is) and editing about 4 other files. (I wonder if sqlite's amalgamation script could help make the process easier, or if it is sqlite specific?)

technosaurus, In Puppy 214R, Dougal removed many busybox applets and modified the init script, it´s a good example of size reduction that you should look.

It´s very hard to remove any applet that is not actually used by init script, anyway I think a review for init is necessary.

For example he removed the "expr" applet and replaced the implicated code in favor of the "let" builtin function. That´s seems also a faster function.

clarf

[technosaurus]

I know ttuuxxx still compiles software with -march=i386.

As do I - when the speed of the program is inconsequential, because it does typically produce smaller code especially if combined with -mpreferred-stack-boundary=2 and some other flags.

It is perfectly acceptable to lower the architecture for a build (because it will still run on all systems that run on the standard higher architecture), but if you go above the standards set as the norm, it should be annotated. Some areas where a higher architecture would be acceptable are encoders/decoders etc... where a drastic improvement is gained or performance on the lower architecture is deemed to be unacceptable (I don't know of any that meet the latter for 586 but for 486 there are many)

[ttuuxxx]

technosaurus If the #1 most popular distro Ubuntu and then you have Debian, uses i386 then I think we should go that way. Plus new products like my surfboard pc I purchased like 2 weeks ago uses vortex86 http://murga-linux.com/puppy/viewtopic.php?t=59466
the vortex86 cpu is going to expanded into other pc's also, they already have a ipad clone version that uses it also, plus the edubook.
When I made up the VLC package in 4.0, The resources were way lower than Mplayer and Gxine. I built it as i386, where as Barry was building as i486. Don't forget the vlc had sdl and wxgtk , Here's a couple of user quotes from the VLC 8.6h page

Playing 'Lonesome Day Blues' from MP3 file on the hard disk. This notepad is a Toshiba Portege 3110CT with 128mb ram and a 300mhz processor (a PII).

Did comparison of gzine (with visualisation turned off) and VLC:

Gxine came out at 124% mem use and 38% CPU
VLC looked very good with 86% mem and 3% (sometimes 2%!) CPU usage. Unbelievable?

with some mpg video off a hard drive gxine 130%mem 98%cpu and VLC 112%mem and 89%cpu - but have to say the display at that point from VLC was roughly 3 times the size which makes a difference. plus not jerky like gxine.

VLC looks much better too Smile

I'm not too sure about your statement "Some areas where a higher architecture would be acceptable are encoders/decoders" The above is proof supporting the lower i386. Also The vlc package is double the Gxine size but takes way less resources, actually there were a few post that some people could play dvd's on there low spec pc's where they couldn't on Gxine because gxine was choppy.
ttuuxxx

[ttuuxxx]

Lets stay focussed on what puppy is and what it isn't, Puppy isn't Arch Linux -i686, Puppy is made for breathing new life into older pc's and also has supports bleeding edge technologies. But we still have many users using i486 pc's. heck most of my pc's other than the the surfboard are i686 dual-core, but I'm pretty much against the extra kernel bloat for the extra cores that have to be included by default for a minimal increase in speed that we have to force on all users to which most don't have more than 1 core cpu's.
ttuuxxx

[jemimah]

Well is the mission to support just old computers, or all underpowered computers? I don't see how we get around either making compromises - or making multiple versions.

[ttuuxxx]

Well is the mission to support just old computers, or all underpowered computers? I don't see how we get around either making compromises - or making multiple versions.

naaa jemimah Puppy is usually well rounded as know, and I don't think its time to stop supporting older hardware, and some things keep bloating puppy up, like gnome libs or big fat kernels, larger Xorg versions. etc If we don't get handle on things and we let things fly like from 4.0 to 5.0 with a 50% increase in size. and keep on that path then puppy 6 should be 200MB, lol I know it won't ever be that bad maybe puppy 10
Multiple versions is a pain, I think we should build puppy as i386, I only compile as i386 and do pretty well Or stick with Barry's default i486 but I'll still compile as i386 only. But noway should we go to 586 or 686, its not the time for that. We still get lots of users recycling older pc/laptops. There are lots of other distros who can handle 586,686 etc
My first pick is i386, i486 as second and last.
ttuuxxx

[jemimah]

naaa jemimah Puppy is usually well rounded as know, and I don't think its time to stop supporting older hardware, and some things keep bloating puppy up, like gnome libs or big fat kernels, larger Xorg versions. etc If we don't get handle on things and we let things fly like from 4.0 to 5.0

The latest crop of netbooks cannot be made to work on anything but a very recent Xorg and kernel. I won't argue over the compile arch - but if you expect to support more hardware over time - it's inevitable that the number and size of the drivers you need will grow. We can of course reduce the size by removing support for very old hardware.