32 bit deb-based systems

wanderer · Post by **wanderer** » Wed Aug 19, 2020 9:40 pm

hi all

in my eternal quest to be annoying
i have decided to become a fanboy
for deb based 32 bit systems

so i am trying all the ones i can find
i am using busterdog which of course is a masterpiece
i am using buster-8 which also is a masterpiece
i am using dpupbuster again a masterpiece
i am trying to set up corepup so it can use debs (i think tinycore already some utilities for this)
i will try to learn and use wiaks dcoredog (edit)

any ones i missed ?

also i wish to continually bring up the subject of a general puppy repo
to reduce our dependency on other distros
as many will transition away from 32 bit

well chew on that

wanderer

Moose On The Loose · Post by **Moose On The Loose** » Wed Aug 19, 2020 11:59 pm

wanderer wrote: ↑Wed Aug 19, 2020 9:40 pm [....]
also i wish to continually bring up the subject of a general puppy repo
to reduce our dependency on other distros
as many will transition away from 32 bit

I am posting this from a 32 bit system based on 528 but with a lot of changes.
You can have most of my work if you want.

Code: Select all

AddedHelp           Includes a script to generate index pages etc
AddIconToPin        Does what the name says
alsamixer           A size adjustment for low res screens
BootManager         A size adjustment for low res screens
clockdisplay        More contrasty colors
CountryWizard       A size adjustment for low res screens
desktopicons        Added a few
DeskTopSize         Slightly improved when change are done
EventManager        I forget what exactly
geany               Make *.bas be taken as BASIC source
HostName            Random string added to prevent two the same
improvedpmount      Improved logic on un-mounting 
improvedpsync       Reformatted dialog for small screens and better functioning
IndentBeforeGUI     When you have a CRT that is weird this makes things better
Menus               Allow new menu major topics to be added by a SFS
NetNeighbor         A "pnethood" that works on nearly totally munged networks
PDFPrinterFix       Sometimes PDF printing fails, normally
PleaseWaitDialog    A nice dialog for asking for waiting
PuppyPinAdjust      A better check the pin file for things off screen
rc.shutdown         A work in progress but works with more cases
RebootDialog        Ask and reboot
samba3              The SAMBA I use because it works
SetFileIcon         A bit of automation
videoplay           Set the player for videos to one that works for each type
wallpaper           An extra few of these
AddedHelp           More help stuff
dosemuAdded         DOSEMU script I did
dosemuCore          A hacked DOSEMU
Electronics         Some nice explanations I've been working on
freepascal          Installed and works
JavaScriptGames     In case you get too bored
JavascriptNonGame   A demo of useful thing
octave              Old version that works
PuppyBasic3-0-0     My modified BASIC
Qcad                2D CAD
stellarium          What are those bright dots in the sky at night
tabasm              A bad 8051 microcontroller assembler
tictac              The worst version known to man
USB3                Driver for USB3 for old puppy
view232             Picocom with some added features
XBill               Wack-A-mole game with moles looking like a Mr. Bill

greengeek · Post by **greengeek** » Thu Aug 20, 2020 12:51 am

wanderer wrote: ↑Wed Aug 19, 2020 9:40 pm
also i wish to continually bring up the subject of a general puppy repo
to reduce our dependency on other distros
as many will transition away from 32 bit

Over the years i have seen a number of comments saying that packages should only be used on the systems for which they have been specifically compiled.

In my experience this is not really true - but then i avoid save files and tend to only load the package i most need on the day. So i have probably been lucky to avoid the incompatibilities that would result from mixing different puppy packages into a cumulative savefile.

So - given the basic caveat that a mixed repo could be dangerous - i have some questions that reflect my interest in the idea of a collective 32bit repo:

- Could such a repo offer a section of "statically compiled" packages that would be broadly suitable for a range of pups?

- Could a standard be adopted where a .pet name also specifies the pup on which it was compiled (or the kernel number if that is applicable)? (I know this is usually done for say nvidia drivers etc but maybe this should be more widely used)

- Do other people have knowledge of which substitutions/crossbreedings work effectively? (In my experience a lot of .deb files run well in Slacko 5.6 but some versions are more appropriate than others. eg Jessie, stretch etc etc. Such info could be available as a 'newbie" guideline)

- Does it really matter where a .pet came from if it seems to work fine during a fresh session where nothing is written back to a savefile?

dancytron · Post by **dancytron** » Thu Aug 20, 2020 1:26 am

Radky's Stretch Puppy and Buster Puppy

wanderer · Post by **wanderer** » Thu Aug 20, 2020 4:41 am

hi guys

lets use this thread to organize and discuss this project

just gather together
1. a list of deb based 32 bit systems (maybe links) doesn't really have to be just deb based
and
2. a list of 32 bit apps that might run on them (maybe links) thanks for the idea greengeek

just informally
no work needs to be done
just to have fun

like moose on the loose can give a link to his stuff
some of us can try it

or someone can suggest a 32 bit deb based system for us to try

as to whether the app will work on that system
it is my experience that it may and it may not
just try it

for example i have gotten fredx portable firefox to run on corepup/tinycore
by just loading some new libraries from tinycores firefox

nothing to lose

wanderer

nic007 · Post by **nic007** » Thu Aug 20, 2020 5:34 am

Are .deb packages more likely to work on all (more) debian based systems (older to newer)?

wanderer · Post by **wanderer** » Thu Aug 20, 2020 6:09 am

the idea of deb based systems is to have a common 32 bit base with long term support
and debian and devuan seem like they will support 32 bit for the foreseeable future

however there are many distros that are independent
tinycore for example
and they will not abandon 32 bit any time soon

puppy used to be independent until barry k made it able to use packages from the main distros
this is an advantage for many reasons
but it has its drawbacks
notably that a change in the dependent distro could cause problems

debs should work more reliably on debian based systems old or new
however many apps are pretty much distro independent
for example xterm will work on virtually any system

most distros have a few basic apps that are used 99 percent of the time

a window manager
a browser
and internet connection system
a media player
and editor
an xterm
a file manager

and these (i assume) can be made pretty much distro independent
so putting together some apps on a base shouldn't be much of a problem
for example tinycore (independent) has just about every app you could want in its repos

other stuff may work or it may not
but if it doesn't work just try something else

its not like we would be actually building the system
we would just be snapping things in and seeing if we can get them to work

the gurus have already done all the work by building the systems

anyway the first step is to play with some systems that are already built
and try to snap in some stuff

i guess deb pet sfs/tcz are some packages that might work

the most important thing is to just learn and have fun
its been really cool for me to try out the different systems
now i have 4 or 5 distros that will do the job for me
thats useful

wanderer

nic007 · Post by **nic007** » Thu Aug 20, 2020 7:49 am

My question was just in general as in comparison to say standard Ubuntu applications.

greengeek · Post by **greengeek** » Thu Aug 20, 2020 8:17 am

I think Ubuntu is built on debian isn't it?

nic007 · Post by **nic007** » Thu Aug 20, 2020 8:45 am

It's a fork but software packages often differ (I think).

wanderer · Post by **wanderer** » Thu Aug 20, 2020 9:24 am

as i understand it

the packages are compiled for that particular distro
against the same libs etc
so it would be just chance if they worked in another distro
even one that was closely related

only the gurus can do that

im thinking more of gathering things together
(figuratively because it will just be links etc)
like deb based distros that are already built
and pets debs etc that may work in them
so we have a variety of 32 bit stuff we can use

i assume the gurus will continue to make new distros
based on or compatible with debian and devuan for us to use
and many of them have their own repos of apps

also i know by playing with things
that a lot of apps will work in distros they weren't compiled for
like jwm, xterm, emelfm, rox filer, fredx portable firefox, etc
so many of the basic apps can be distro agnostic

as i said so far i am using
busterdog
busterpup-8
dpupbuster
corepup/tinycore
and i will see if i can learn and use dcoredog (edit)
and of course there is a lot of debian stretch distros

so we should have a lot to play with

anyway its useful
we end up having a lot of 32 bit stuff

and its fun to talk about

wanderer

nic007 · Post by **nic007** » Thu Aug 20, 2020 9:29 am

Cheers. I like the snap packages idea and so on. Anything to make things more universal.

Post by **mikewalsh** » Thu Aug 20, 2020 10:50 am

That's a good idea, wanderer. I don't care what the "oracles" pronounce about 32-bit being dead, there's still a ton of 32-bit hardware AND software out there, and, of course, any 64-bit CPU will run them anyway.

And I find 32-bit just seems to have the edge, speed-wise.

nic007 wrote: ↑Thu Aug 20, 2020 9:29 am Cheers. I like the snap packages idea and so on. Anything to make things more universal.

They're a good idea, certainly. However, what isn't so generally known is that Snaps (like Flatpaks) need their own "infrastructure" installed before you can even start using them. That said, some Puppians have already found ways of extracting, and getting-at the content.

It's why I prefer AppImages as a 'universal', portable format. No, not all AppImages WILL run.....but enough DO to make the format worthwhile pursuing for Puppy. Those that have been "properly" constructed are more likely to run than those which are simply badly re-packaged .debs/.rpms, since these are always looking for system dependencies. There's still too many packagers out there who don't test on any other than their own daily drivers, forgetting that the dependency situation may be different for other distros.....

It's usually system stuff like dbus that lets down many otherwise viable AppImages.

Just my two-penn'orth, FWIW. (*shrug*)

Mike.

Dingo · Post by **Dingo** » Thu Aug 20, 2020 4:39 pm

mikewalsh wrote: ↑Thu Aug 20, 2020 10:50 am That's a good idea, wanderer. I don't care what the "oracles" pronounce about 32-bit being dead, there's still a ton of 32-bit hardware AND software out there, and, of course, any 64-bit CPU will run them anyway.

And I find 32-bit just seems to have the edge, speed-wise.

nic007 wrote: ↑Thu Aug 20, 2020 9:29 am Cheers. I like the snap packages idea and so on. Anything to make things more universal.
They're a good idea, certainly. However, what isn't so generally known is that Snaps (like Flatpaks) need their own "infrastructure" installed before you can even start using them. That said, some Puppians have already found ways of extracting, and getting-at the content.

It's why I prefer AppImages as a 'universal', portable format. No, not all AppImages WILL run.....but enough DO to make the format worthwhile pursuing for Puppy. Those that have been "properly" constructed are more likely to run than those which are simply badly re-packaged .debs/.rpms, since these are always looking for system dependencies. There's still too many packagers out there who don't test on any other than their own daily drivers, forgetting that the dependency situation may be different for other distros.....

It's usually system stuff like dbus that lets down many otherwise viable AppImages.

Just my two-penn'orth, FWIW. (*shrug*)

Mike.

What do you think about program portabilization made with the help of magicermine?

I had many years ago for free a trial of a very expensive license of magicermine and made some packages:
http://dokupuppylinux.info/stand_alone_packages_index (sorry, facebook account needed for now, I'll strive to move on another host as soon as possible)

All Qt4 packages were made in puppy 5.2.5 and converted to standalone with magicermine

wanderer · Post by **wanderer** » Thu Aug 20, 2020 8:44 pm

yes that is an important idea

what would be a good universal format for components for a deb based 32 bit system

deb, pet, sfs/tcz/sce, fredx portable system ?

the main systems i see now are

Buster-8 - a woof-ce system - pet sfs
Dpupbuster - a woof-ce system - pet sfs
BusterDog - a debian system - deb
dcoredog - a tinycore system - deb sce/sfs
corepup - a tinycore system - tcz/sfs

wanderer

Moose On The Loose · Post by **Moose On The Loose** » Thu Aug 20, 2020 11:18 pm

wanderer wrote: ↑Thu Aug 20, 2020 4:41 am [....]
like moose on the loose can give a link to his stuff
some of us can try it
[...]

I am starting to put it together is a form folks can try out.

I will be posting a link to 2 ISO images.
The idea is you put xxxCD1.iso into VirtuaBox as the CD and boot.
You need a few gig of "hard drive" in the virtual machine.
Hopefully from there, the instructions will get you to the point of fiddling with it.
I would like to migrate to a new non-PAE kernel
The version I have done works well on very weak processors.

wanderer · Post by **wanderer** » Fri Aug 21, 2020 7:39 am

hi moose on the loose

what kind of a system are you using
where did it originate
is it puppy based or something else

wanderer

mikeslr · Post by **mikeslr** » Fri Aug 21, 2020 2:29 pm

Just 'brain-storming' an idea suggested by 'tOther' Mike.

The rationale of AppImages is that they contain all the 'bits & pieces' required by the application so that nothing is required from the operating system which uses them beyond a link. But AppImage publishers only test against 3 or 4 Major Distros; and now probably aren't building 32-bit applications. The problem using them under Puppies is that like infinity nothing is pretty all encompassing.

We, however, are not dependent on what others do. What is actually required to create a 'kind-of' AppImage is place all necessary files in one folder and run fredx181's Create Portable AppImage, http://murga-linux.com/puppy/viewtopic. ... 09#1011814.

Of course, like Nothing all is also pretty big.

But AppImages would solve the glibc problem and others you otherwise run into when attempting to transpose an application created under one Puppy to a range of Puppies employing an assortment of foundation libraries.

Full disclosure: I've never used Create Portable AppImage in Chroot mode. That and "LD_LIBRARY_PATH=" are concepts I've noted but haven't gotten my head around.

Still brainstorming: This kind-of segues into the suggestion of a Puppy built to run current web-browsers but otherwise using gtk2 or even gtk1 applications.

Post by **mikewalsh** » Fri Aug 21, 2020 5:13 pm

Now then, Michael. Pull up a chair....

To expand on your 'concept', I'm wondering if you're proposing we construct these "kind-of AppImages" along the same lines as the glibc-tweaked 'portable-browser' versions of, say, Palemoon 27.9.4_SSE.....where I built a special version of that to not only permit running on older, non-SSE2 hardware, but an elderly Puppy, too? If it wasn't for watchdog's perseverance, even that would have been dead in the water....

It would have to be set-up along the same lines as a 'portable' browser, I think; a self-contained 'libs' directory, plus a glibc directory along with associated launch script (fortunately, I've had experience of making both of those work, though not necessarily together & at the same time. I also know from conversations with Fred that creating "home-grown" AppImages isn't quite as straight-forward as you might think. The self-extracting scripts are more reliable in that respect, though I wouldn't like to say quite how large you can go with them, size-wise.

I've long had a sneaking suspicion that the NVidia driver .run files are in fact a kind of "self-extracter".

----------------------------------------------------

The main snag I foresee with these is the necessity to constantly re-build them as apps/programs update themselves. The nice thing with at least the Firefox/Palemoon portables is that they update themselves "in-situ", since they were always designed to run from a single directory. I wish the 'Clones' would do that, too, but the Linux Chromium-based update mechanism has never been anywhere near as reliable for us, unfortunately.....unlike its Windoze counterpart.

On top of which, I'm no longer the best person for the job of testing-as-you-build, given that this new HP with UEFI just will NOT let me run older Puppies any more.

It's certainly worth thinking about. It'll need to have liberal use made of "ldd", too.....

Mike.

mikeslr · Post by **mikeslr** » Fri Aug 21, 2020 6:51 pm

Mike, I was looking at it the other way around. A "base" 'bare-bones' Puppy would have to be 'up-to-date' at least sufficiently to make use of current (probably portable) Web-browsers. But all the applications you usually find on the Menu under Graphics, Documents, Business, Personal, Multimedia and a good bit of Utilities could be light-weight gtk2, even gtk1 AppImages. Maybe packaged as AppImage Suites.

Moose On The Loose · Post by **Moose On The Loose** » Fri Aug 21, 2020 7:40 pm

wanderer wrote: ↑Fri Aug 21, 2020 7:39 am hi moose on the loose

what kind of a system are you using
where did it originate
is it puppy based or something else

wanderer

Get the CD images here and try them in VirtualBox on on a physical machine.
It is the legacy boot only

https://drive.google.com/drive/folders/ ... sp=sharing

This started out as Puppy-Lucid-528
It was a fairly old 32 bit Puppy that I was using.
I made a start on migrating to PreciseLite but I discovered that there was more in that that "didn't work right" than there was in the 528. Thus I figured I should keep looking for one to migrate to.

Basically what I have done is make one by one changes by adding files to the image of the system with a script.
I took some stuff out and made a slightly smaller base SFS for the system. This works as a "rescue disk".
The added stuff is in two SFSs so I could keep the ISOs down at CD sized. My script packs as much as it can into the first "Added" SFS and then the rest goes in the 2nd one on the 2nd CD

I went with packing it into a low number of SFSs so I could add more later.
Hopefully, it will work for you so you can see what I may have missed or done wrong.
BTW: Some things do have "known bugs" that I couldn't find. If folks want those features, I may dig in a bit more.

In any case, I think a low demand 32 bit system is a very good idea. So I will help here and there.
I am working currently so night a weekends are the time I can use.

wanderer · Post by **wanderer** » Fri Aug 21, 2020 8:20 pm

hi moose on the loose

could not download your isos
tried multiple times
maybe server you are using

don't stress about it
just describe what you are doing

if you are working you got to take it easy

wanderer

Post by **mikewalsh** » Fri Aug 21, 2020 9:07 pm

mikeslr wrote: ↑Fri Aug 21, 2020 6:51 pm Mike, I was looking at it the other way around. A "base" 'bare-bones' Puppy would have to be 'up-to-date' at least sufficiently to make use of current (probably portable) Web-browsers. But all the applications you usually find on the Menu under Graphics, Documents, Business, Personal, Multimedia and a good bit of Utilities could be light-weight gtk2, even gtk1 AppImages. Maybe packaged as AppImage Suites.

Uh-huh. I see where you're coming from. Leave it with me, and I'll have a think about it for a few days.....sketch out some ideas, like.

I think it's an idea worth pursuing, y'know.... So; like a "bare-bones" version of, say, DPup Stretch or Buster?

Ya got me thinking, now..!

Mike.

wanderer · Post by **wanderer** » Fri Aug 21, 2020 9:16 pm

hi guys

i am also very interested in a barebones puppy from debian
that could be added to with (maybe portable) modules

i think that is what has been missing for a long time (maybe forever)

waiting with baited breath

wanderer

Moose On The Loose · Post by **Moose On The Loose** » Sat Aug 22, 2020 1:02 am

wanderer wrote: ↑Fri Aug 21, 2020 8:20 pm could not download your isos

It is the weekend now.
What did you see? What happened?
I was intending to share this thing with others too.

wanderer · Post by **wanderer** » Sat Aug 22, 2020 1:28 am

hi moose on the loose

downloads started but never completed
in the end no iso

wanderer

darry19662018 · Post by **darry19662018** » Sat Aug 22, 2020 6:44 am

Hi Wanderer and Mike and Mike and others,
Here is a Dpup Stretch stripped down like you guys want to start with - did this about a year ago ......
https://archive.org/details/stretch7.5onebonek4.1.48

nic007 · Post by **nic007** » Sat Aug 22, 2020 7:10 am

I like the way Stretch handles memory. I was wandering if this is kernel specific related or just how debian systems operate in general.

Moose On The Loose · Post by **Moose On The Loose** » Sat Aug 22, 2020 3:22 pm

wanderer wrote: ↑Sat Aug 22, 2020 1:28 am hi moose on the loose

downloads started but never completed
in the end no iso

wanderer

They are on a "google drive" and my try at the download just worked but took several minutes to compete.
Have you downloaded 650Meg things before with no issue?

Ideally someone who is not me should check to see if the download works for them.
If I check, the googles will know it is me and may treat me differently.

Anybody's help will be accepted here with much thanks.

Moose On The Loose · Post by **Moose On The Loose** » Sat Aug 22, 2020 3:33 pm

darry19662018 wrote: ↑Sat Aug 22, 2020 6:44 am Hi Wanderer and Mike and Mike and others,
Here is a Dpup Stretch stripped down like you guys want to start with - did this about a year ago ......
https://archive.org/details/stretch7.5onebonek4.1.48

Sadly that is a PAE kernel so on a very minimal system it won't boot.

Puppy Linux Discussion Forum

32 bit deb-based systems

32 bit deb-based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

32-bit AppImages

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems

Re: 32 bit deb based systems