32 bit deb-based systems
Moderator: Forum moderators
Re: 32 bit deb based systems
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
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
Last edited by wanderer on Thu Aug 20, 2020 9:34 pm, edited 1 time in total.
Re: 32 bit deb based systems
Cheers. I like the snap packages idea and so on. Anything to make things more universal.
- mikewalsh
- Moderator
- Posts: 6115
- Joined: Tue Dec 03, 2019 1:40 pm
- Location: King's Lynn, UK
- Has thanked: 779 times
- Been thanked: 1952 times
Re: 32 bit deb based systems
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.
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.
And I find 32-bit just seems to have the edge, speed-wise.
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.
Re: 32 bit deb based systems
What do you think about program portabilization made with the help of magicermine?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.
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.
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
Re: 32 bit deb based systems
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
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
Last edited by wanderer on Fri Aug 21, 2020 12:23 am, edited 2 times in total.
-
- Posts: 54
- Joined: Fri Jul 24, 2020 2:26 pm
- Has thanked: 5 times
- Been thanked: 2 times
Re: 32 bit deb based systems
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.
Re: 32 bit deb based systems
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
what kind of a system are you using
where did it originate
is it puppy based or something else
wanderer
- mikeslr
- Posts: 2944
- Joined: Mon Jul 13, 2020 11:08 pm
- Has thanked: 178 times
- Been thanked: 905 times
32-bit AppImages
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.
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.
- mikewalsh
- Moderator
- Posts: 6115
- Joined: Tue Dec 03, 2019 1:40 pm
- Location: King's Lynn, UK
- Has thanked: 779 times
- Been thanked: 1952 times
Re: 32 bit deb based systems
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.
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
- Posts: 2944
- Joined: Mon Jul 13, 2020 11:08 pm
- Has thanked: 178 times
- Been thanked: 905 times
Re: 32 bit deb based systems
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.
-
- Posts: 54
- Joined: Fri Jul 24, 2020 2:26 pm
- Has thanked: 5 times
- Been thanked: 2 times
Re: 32 bit deb based systems
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.
Re: 32 bit deb based systems
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
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
- mikewalsh
- Moderator
- Posts: 6115
- Joined: Tue Dec 03, 2019 1:40 pm
- Location: King's Lynn, UK
- Has thanked: 779 times
- Been thanked: 1952 times
Re: 32 bit deb based systems
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.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.
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.
Re: 32 bit deb based systems
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
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
-
- Posts: 54
- Joined: Fri Jul 24, 2020 2:26 pm
- Has thanked: 5 times
- Been thanked: 2 times
Re: 32 bit deb based systems
It is the weekend now.
What did you see? What happened?
I was intending to share this thing with others too.
Re: 32 bit deb based systems
hi moose on the loose
downloads started but never completed
in the end no iso
wanderer
downloads started but never completed
in the end no iso
wanderer
-
- Posts: 453
- Joined: Sat Dec 14, 2019 12:24 am
- Has thanked: 54 times
- Been thanked: 65 times
Re: 32 bit deb based systems
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
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
Re: 32 bit deb based systems
I like the way Stretch handles memory. I was wandering if this is kernel specific related or just how debian systems operate in general.
-
- Posts: 54
- Joined: Fri Jul 24, 2020 2:26 pm
- Has thanked: 5 times
- Been thanked: 2 times
Re: 32 bit deb based systems
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.
-
- Posts: 54
- Joined: Fri Jul 24, 2020 2:26 pm
- Has thanked: 5 times
- Been thanked: 2 times
Re: 32 bit deb based systems
Sadly that is a PAE kernel so on a very minimal system it won't boot.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
- fredx181
- Posts: 2997
- Joined: Tue Dec 03, 2019 1:49 pm
- Location: holland
- Has thanked: 364 times
- Been thanked: 1272 times
- Contact:
Re: 32 bit deb based systems
electropupCD1.iso downloaded complete for me.moose on the loose wrote:Ideally someone who is not me should check to see if the download works for them.
@wanderer Could it be that you downloaded to /root and that there's not enough space there?
Fred
Re: 32 bit deb based systems
hi moose on the loose and fredx
yes probably the size of the isos
will try again
hi darry tried your barebones strech
very nice
moose on the loose try corepup (made from tinycore 641)
it is made to run on 486 it should work for you
which brings me to my suggestion
since we are talking about all 32 bit deb based (or can be made deb based) systems
and not just puppy
we have
debian based - fredx busterdog
woof-ce based - many
tinycore based - corepup dcoredog
others of which i am not familiar with slitaz etc
by far the most minimal modular and easiest to work with are tinycore based
barebones for them is 9 megs (core) you can't get any more barebones than that
the iso consists of
a bootloader - can be syslinux or grub whatever
a kernal - whatever you like
an initrd (6 megs) which is the skeleton of the system
modules to add to the system (tcz which are sfs files)
and thats it
you can replace add and subtract pieces of the system
just by removing and adding them to the iso
if you convert debs to tcz it is deb based
(edit) in dcore there is a script that downloads debs and bundles them into sce
if that script could be modified to just make individual tcz
it would be a major improvement
(but way beyond me)
for all of these systems just convert the pet deb sfs or tcz to the proper format and it may work
if not you may have to fiddle with the dependencies
like i mentioned i got fredx portable firefox to work in corepup just by adding newer libs from a newer tinycore firefox
i have no dog in this race
since that is what i am working on now
and have been for a while
but
you can have an iso to work with in a few minutes
and a new iso in a few minutes more
and a new iso in a few minutes more
no need to wait for complex build systems
just something to consider
wanderer
yes probably the size of the isos
will try again
hi darry tried your barebones strech
very nice
moose on the loose try corepup (made from tinycore 641)
it is made to run on 486 it should work for you
which brings me to my suggestion
since we are talking about all 32 bit deb based (or can be made deb based) systems
and not just puppy
we have
debian based - fredx busterdog
woof-ce based - many
tinycore based - corepup dcoredog
others of which i am not familiar with slitaz etc
by far the most minimal modular and easiest to work with are tinycore based
barebones for them is 9 megs (core) you can't get any more barebones than that
the iso consists of
a bootloader - can be syslinux or grub whatever
a kernal - whatever you like
an initrd (6 megs) which is the skeleton of the system
modules to add to the system (tcz which are sfs files)
and thats it
you can replace add and subtract pieces of the system
just by removing and adding them to the iso
if you convert debs to tcz it is deb based
(edit) in dcore there is a script that downloads debs and bundles them into sce
if that script could be modified to just make individual tcz
it would be a major improvement
(but way beyond me)
for all of these systems just convert the pet deb sfs or tcz to the proper format and it may work
if not you may have to fiddle with the dependencies
like i mentioned i got fredx portable firefox to work in corepup just by adding newer libs from a newer tinycore firefox
i have no dog in this race
since that is what i am working on now
and have been for a while
but
you can have an iso to work with in a few minutes
and a new iso in a few minutes more
and a new iso in a few minutes more
no need to wait for complex build systems
just something to consider
wanderer
-
- Posts: 54
- Joined: Fri Jul 24, 2020 2:26 pm
- Has thanked: 5 times
- Been thanked: 2 times
Re: 32 bit deb based systems
Thanks for checking.
I thought that if you stuffed your save file full it made a rude message happen so I had sort of ruled out a full save file. Still setting it up so that Downloads is actually a directory under /mnt/home is a good thing to do for this.
Maybe I should make some nifty little script that makes that happen.
I have also, from time to time, made it so that /tmp is also a directory under /mnt/home.
-
- Posts: 54
- Joined: Fri Jul 24, 2020 2:26 pm
- Has thanked: 5 times
- Been thanked: 2 times
Re: 32 bit deb based systems
A few thoughts:
I may be dreaming this but it seems to me that I heard that a new kernel version used PAE if available but didn't choke if it wasn't. If so that seems a good thing to include in a 32bit version.
Ideally the distro should come with a web browser on the CD (In the ISO image) somehow.
Not everyone has fast internet and the delay in getting a basic browser can be trouble.
So far, seamonkey seems to be the least awful option. Palemoon also seems OK
Ideally the system should be usable on a 640x480 display. Some people have high-res monitors but low-res eyeballs. Most monitors will still go 640x480.
To the degree we can, stuff that doesn't need to go fast, should be scripts. For example, the help system being all HTML and firing up the web browser is a good start. My script for making it easy to add help, is the improvement on this I suggest. Some javascript games in the "fun" menu are nice too.
We may also want to define the term "works on xxx" for software as meaning you boot from the original ISO, add the "xxx" and it works with no further action. No "oh by the way you also need yyy" allowed.
I may be dreaming this but it seems to me that I heard that a new kernel version used PAE if available but didn't choke if it wasn't. If so that seems a good thing to include in a 32bit version.
Ideally the distro should come with a web browser on the CD (In the ISO image) somehow.
Not everyone has fast internet and the delay in getting a basic browser can be trouble.
So far, seamonkey seems to be the least awful option. Palemoon also seems OK
Ideally the system should be usable on a 640x480 display. Some people have high-res monitors but low-res eyeballs. Most monitors will still go 640x480.
To the degree we can, stuff that doesn't need to go fast, should be scripts. For example, the help system being all HTML and firing up the web browser is a good start. My script for making it easy to add help, is the improvement on this I suggest. Some javascript games in the "fun" menu are nice too.
We may also want to define the term "works on xxx" for software as meaning you boot from the original ISO, add the "xxx" and it works with no further action. No "oh by the way you also need yyy" allowed.
Re: 32 bit deb-based systems
well it looks like 32 bit debian stuff is alive and well
are you guys still thinking of a barebones 32 bit debian based iso
maybe with appimages
wanderer
are you guys still thinking of a barebones 32 bit debian based iso
maybe with appimages
wanderer
-
- Posts: 54
- Joined: Fri Jul 24, 2020 2:26 pm
- Has thanked: 5 times
- Been thanked: 2 times
Re: 32 bit deb-based systems
My thinking goes a lot like this:
On the CD (In the ISO) there is enough to boot the extremely simplified system plus a second SFS.
When booted with only the first SFS there is practically nothing but the very minimum for rescuing files off a broken Windows machine. There is only one simple background. There is nothing in the "fun" menu. No music playing or anything like that. There may not even be help in this one.
After boot a "welcome" message appears from a script that offers to load the 2nd SFS and explains a little.
When booted with the 2nd SFS included, you have what is still a fairly stripped down system but quite a few additional features are in there. Basically, things are added with a limit of it still fitting onto one CD.
This system has all the "basics" on it. Sound files and videos will play. There is some sort of web browser that can do HTTPS well enough so that the user can go get the rest from a web site if that gets set up.
From here, the system allows specialized features and a better web browser to be added etc.
Re: 32 bit deb-based systems
hi moose on the loose
sounds interesting
the most important thing is that it works on your system
have you tried to put fredx portable firefox in it
that would be an up to date browser with no extra overhead
wanderer
sounds interesting
the most important thing is that it works on your system
have you tried to put fredx portable firefox in it
that would be an up to date browser with no extra overhead
wanderer
- greengeek
- Posts: 1378
- Joined: Thu Jul 16, 2020 11:06 pm
- Has thanked: 525 times
- Been thanked: 191 times
Re: 32 bit deb-based systems
Hi MOTL - i just booted CD1.iso (CD2.iso does not boot for me) and this is quite a nimble and flexible system.Moose On The Loose wrote: ↑Mon Aug 24, 2020 2:55 pm
My thinking goes a lot like this:
On the CD (In the ISO) there is enough to boot the extremely simplified system plus a second SFS.
...
When booted with the 2nd SFS included, you have what is still a fairly stripped down system but quite a few additional features are in there. Basically, things are added with a limit of it still fitting onto one CD.
I was surprised that i was able to mount the "ADDED sfs" by mounting "CD1" (sr0) after boot as i have previously been told that it is not possible to include extra software inside an iso - yet it certainly works here.
And i did not make a savefile.
I like the idea of a stripped system that can then immediately clickload an extra sfs from boot CD after boot.
Have you thought about starting a thread for this? This is a pup design that deserves to be used and optimised. Keen to ask further questions.
-
- Posts: 54
- Joined: Fri Jul 24, 2020 2:26 pm
- Has thanked: 5 times
- Been thanked: 2 times
Re: 32 bit deb-based systems
What happened when you tried?
You said you didn't make a save file.
CD2 presumes that you booted CD1 and followed the instructions about making a save file etc etc.
CD1 puts the ElectroPup.sfs into your /mnt/home after you made a save file and boot again
It the begs (or is it whines) about wanting the other added stuff from CD2.
Files other than the expected ones that may be on the CD are OK.I was surprised that i was able to mount the "ADDED sfs" by mounting "CD1" (sr0) after boot as i have previously been told that it is not possible to include extra software inside an iso - yet it certainly works here.
Thus I coded a script to pick the added stuff off the CD and it seem to work.
That may explain the problemAnd i did not make a savefile.
I think about many things. At one point I was thinking of making a thread about all the things I changed to make 528 better including the idea of 2 or 3 SFS files.I like the idea of a stripped system that can then immediately clickload an extra sfs from boot CD after boot.
Have you thought about starting a thread for this? This is a pup design that deserves to be used and optimised. Keen to ask further questions.
BTW: As it is the "Help" system should adapt to whether you added 0, 1 or 2 "added" SFSs
The way it works is the help script scans the directory tree of the help and if it sees a directory with no index.html it makes one.
If there is a HTML file in the directory, it grabs the title out of it as the label in the index.
If there is a directory like "Watching_Cat_Videos", it replaces the "_" with spaces and uses that as the label.
This way, what files come in via a SFS are added to the help system.
BTW-BTW: Some of the help files are a bit of a work of art. Some are a bit short on detail.
-
- Posts: 54
- Joined: Fri Jul 24, 2020 2:26 pm
- Has thanked: 5 times
- Been thanked: 2 times
Re: 32 bit deb-based systems
Perhaps "works and is useful" is a better standard.
I have found that some programs "work" but turn out to make life harder rather than easier.
I class MS-Word among those. I really can't fathom why people use it to make some types of documents. It really sucks at doing ordered lists.
I got an old version of seamonkey to work and left it as that.have you tried to put fredx portable firefox in it
that would be an up to date browser with no extra overhead
wanderer
I figured getting all the basics done was the most important 1st step.
BTW: There seems to be no web browser that really get is right.
1) If the page takes a long time to actually load, Chrome says it crashed.
This shows up when your network connection is very slow so downloading a different browser is not an option.
2) There should be a "stop" button that really-really means "stop". When some page with a zillion scripts etc is loading and taking minutes or some page won't let you leave or any of 100s of other things happen, you want to be able to tell the browser to stop absolutely everything but paying attention to the user.
3) When the rendering engine sees something that is not good HTML, it should turn on some sort of marker in the user interface. I am well aware that this marker will be on more than it is off given how crappy web sites are these days.