32 bit deb-based systems

Issues and / or general discussion relating to Puppy

Moderator: Forum moderators

wanderer
Posts: 760
Joined: Mon Jul 13, 2020 7:15 pm
Been thanked: 138 times

Re: 32 bit deb based systems

Post by wanderer »

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
Last edited by wanderer on Thu Aug 20, 2020 9:34 pm, edited 1 time in total.
User avatar
nic007
Posts: 109
Joined: Thu Jul 16, 2020 9:21 am
Has thanked: 1 time
Been thanked: 12 times

Re: 32 bit deb based systems

Post by nic007 »

Cheers. I like the snap packages idea and so on. Anything to make things more universal.
User avatar
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

Post by mikewalsh »

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..... :shock: :(

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

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


Mike. ;)
User avatar
Dingo
Posts: 244
Joined: Sat Aug 01, 2020 3:03 pm
Has thanked: 10 times
Been thanked: 17 times

Re: 32 bit deb based systems

Post by Dingo »

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..... :shock: :(

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

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
Posts: 760
Joined: Mon Jul 13, 2020 7:15 pm
Been thanked: 138 times

Re: 32 bit deb based systems

Post by wanderer »

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
Last edited by wanderer on Fri Aug 21, 2020 12:23 am, edited 2 times in total.
Moose On The Loose
Posts: 54
Joined: Fri Jul 24, 2020 2:26 pm
Has thanked: 5 times
Been thanked: 2 times

Re: 32 bit deb based systems

Post by Moose On The Loose »

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
Posts: 760
Joined: Mon Jul 13, 2020 7:15 pm
Been thanked: 138 times

Re: 32 bit deb based systems

Post by wanderer »

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
User avatar
mikeslr
Posts: 2944
Joined: Mon Jul 13, 2020 11:08 pm
Has thanked: 178 times
Been thanked: 905 times

32-bit AppImages

Post by mikeslr »

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. :o

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. :lol: 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.
User avatar
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

Post by mikewalsh »

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. ;)
User avatar
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

Post by mikeslr »

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
Posts: 54
Joined: Fri Jul 24, 2020 2:26 pm
Has thanked: 5 times
Been thanked: 2 times

Re: 32 bit deb based systems

Post by Moose On The Loose »

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
Posts: 760
Joined: Mon Jul 13, 2020 7:15 pm
Been thanked: 138 times

Re: 32 bit deb based systems

Post by wanderer »

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
User avatar
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

Post by mikewalsh »

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..! :D


Mike. :lol: ;)
wanderer
Posts: 760
Joined: Mon Jul 13, 2020 7:15 pm
Been thanked: 138 times

Re: 32 bit deb based systems

Post by wanderer »

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
Posts: 54
Joined: Fri Jul 24, 2020 2:26 pm
Has thanked: 5 times
Been thanked: 2 times

Re: 32 bit deb based systems

Post by Moose On The Loose »

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
Posts: 760
Joined: Mon Jul 13, 2020 7:15 pm
Been thanked: 138 times

Re: 32 bit deb based systems

Post by wanderer »

hi moose on the loose

downloads started but never completed
in the end no iso

wanderer
darry19662018
Posts: 453
Joined: Sat Dec 14, 2019 12:24 am
Has thanked: 54 times
Been thanked: 65 times

Re: 32 bit deb based systems

Post by darry19662018 »

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
User avatar
nic007
Posts: 109
Joined: Thu Jul 16, 2020 9:21 am
Has thanked: 1 time
Been thanked: 12 times

Re: 32 bit deb based systems

Post by nic007 »

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
Posts: 54
Joined: Fri Jul 24, 2020 2:26 pm
Has thanked: 5 times
Been thanked: 2 times

Re: 32 bit deb based systems

Post by Moose On The Loose »

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
Posts: 54
Joined: Fri Jul 24, 2020 2:26 pm
Has thanked: 5 times
Been thanked: 2 times

Re: 32 bit deb based systems

Post by Moose On The Loose »

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.
User avatar
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

Post by fredx181 »

moose on the loose wrote:Ideally someone who is not me should check to see if the download works for them.
electropupCD1.iso downloaded complete for me.

@wanderer Could it be that you downloaded to /root and that there's not enough space there?

Fred
wanderer
Posts: 760
Joined: Mon Jul 13, 2020 7:15 pm
Been thanked: 138 times

Re: 32 bit deb based systems

Post by wanderer »

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
Moose On The Loose
Posts: 54
Joined: Fri Jul 24, 2020 2:26 pm
Has thanked: 5 times
Been thanked: 2 times

Re: 32 bit deb based systems

Post by Moose On The Loose »

fredx181 wrote: Sat Aug 22, 2020 5:14 pm electropupCD1.iso downloaded complete for me.

@wanderer Could it be that you downloaded to /root and that there's not enough space there?

Fred
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.
Moose On The Loose
Posts: 54
Joined: Fri Jul 24, 2020 2:26 pm
Has thanked: 5 times
Been thanked: 2 times

Re: 32 bit deb based systems

Post by Moose On The Loose »

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.
wanderer
Posts: 760
Joined: Mon Jul 13, 2020 7:15 pm
Been thanked: 138 times

Re: 32 bit deb-based systems

Post by wanderer »

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
Moose On The Loose
Posts: 54
Joined: Fri Jul 24, 2020 2:26 pm
Has thanked: 5 times
Been thanked: 2 times

Re: 32 bit deb-based systems

Post by Moose On The Loose »

wanderer wrote: Sun Aug 23, 2020 7:26 pm 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
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.
wanderer
Posts: 760
Joined: Mon Jul 13, 2020 7:15 pm
Been thanked: 138 times

Re: 32 bit deb-based systems

Post by wanderer »

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
User avatar
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

Post by greengeek »

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.
Hi MOTL - i just booted CD1.iso (CD2.iso does not boot for me) and this is quite a nimble and flexible system.
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.
Moose On The Loose
Posts: 54
Joined: Fri Jul 24, 2020 2:26 pm
Has thanked: 5 times
Been thanked: 2 times

Re: 32 bit deb-based systems

Post by Moose On The Loose »

greengeek wrote: Tue Aug 25, 2020 12:40 am Hi MOTL - i just booted CD1.iso (CD2.iso does not boot for me) and this is quite a nimble and flexible system.
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.
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.
Files other than the expected ones that may be on the CD are OK.
Thus I coded a script to pick the added stuff off the CD and it seem to work.
And i did not make a savefile.
That may explain the problem
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.
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.

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.
Moose On The Loose
Posts: 54
Joined: Fri Jul 24, 2020 2:26 pm
Has thanked: 5 times
Been thanked: 2 times

Re: 32 bit deb-based systems

Post by Moose On The Loose »

wanderer wrote: Mon Aug 24, 2020 6:43 pm hi moose on the loose

sounds interesting

the most important thing is that it works on your system
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.
have you tried to put fredx portable firefox in it
that would be an up to date browser with no extra overhead

wanderer
I got an old version of seamonkey to work and left it as that.
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.
Post Reply

Return to “Users”