Saluki, Puppy Remastered
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
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
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
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
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
@bigbass
I compiled busybox to include the config options. Just runThe 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?
I compiled busybox to include the config options. Just run
Code: Select all
bbconfig >my_dot_config
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?
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Thanks for the quick response is there another way to run that code you posted without installing the new busybox ?@bigbass
I compiled busybox to include the config options. Just run
Code:
bbconfig >my_dot_config
if not could you pastebin it please when you have the time ?
any package slackware compatible will work to build with tgz ,txz ,tlz ,tbzRe:pkgtools - do you have a good reference for putting the build info in the proper format ... and does it work with Amigo's src2pkg?
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
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
@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)
- Attachments
-
- ht21_1.gif
- jemimah's bathtub curve translated into kernel driver support
- (5.23 KiB) Downloaded 1383 times
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
how old
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.
Puppy user since Oct 2004. Want FreeOffice? [url=http://puppylinux.info/topic/freeoffice-2012-sfs]Get the sfs (English only)[/url].
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
Re: how old
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=i486raffy wrote: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.
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
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?)
- Attachments
-
- busybox-technosaurified.tar.gz
- (47.19 KiB) Downloaded 330 times
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
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.technosaurus wrote: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
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I need to upgrade to a different kernel so that rfkill.h is available in order to make it compile.jemimah wrote: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 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.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Re: how old
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).technosaurus wrote: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
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.technosaurus wrote: 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?)
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
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
Re: how old
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.clarf wrote:I know ttuuxxx still compiles software with -march=i386.
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)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
- ttuuxxx
- Posts: 11171
- Joined: Sat 05 May 2007, 10:00
- Location: Ontario Canada,Sydney Australia
- Contact:
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
ttuuxxx
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
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.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
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)
- ttuuxxx
- Posts: 11171
- Joined: Sat 05 May 2007, 10:00
- Location: Ontario Canada,Sydney Australia
- Contact:
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
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)
- ttuuxxx
- Posts: 11171
- Joined: Sat 05 May 2007, 10:00
- Location: Ontario Canada,Sydney Australia
- Contact:
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 10jemimah wrote: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.
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
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)
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.ttuuxxx wrote: 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