Best 32 bit version with support beyond 2023?

[Kjellinux]

@peebee

Open a terminal (lxterminal) and type abiword - highlight (select) any error messages and copy (edit - copy) - then paste them here

Code: Select all

# abiword
Aborted
# 

Exact details of your "initial settings" please - which language, which timezone, which etc.

Screenshot.png (75.61 KiB) Viewed 683 times

[peebee]

Hi @Kjellinux

Abiword on ScPup32 with your Swedish settings works fine for me..........

Does dmesg (run in terminal) give any clues to why it is Aborting for you?

Without being able to duplicate the error I can't proceed further......

Screenshot.png (142.54 KiB) Viewed 668 times

[one]

Hi @peebee and @Kjellinux ,

the problem arises when you select "sv_SE" in the country setting of <quick setup>gui.

There is no langpack_sv_SE to provide full translation for menue and applications so abiword refuses to start. Other applications like gnumeric or mtpaint don't bother and will start anyway - but not abiword.

So leave this part of QuickSetup unchanged to "en_US" and abiword will start normal.

Swedish Timezone and keyboard work as expected ...

peace

PS: the problem is specific to scpup32 - in bionicpup32 abiword starts with swedish translation of the application_menue!

[Kjellinux]

@peebee @one

the problem is specific to scpup32 - in bionicpup32 abiword starts with swedish translation of the application_menue!

It worked with the other versions I tested too (the ones that had abiword preinstalled).

[Kjellinux]

@mikewalsh

Take a look at the vid below; see if it clarifies things any further. Most folks respond to visual demonstration far better than they do written stuff; I know I do.

When I retraced my steps, trying to solve the "Error 13" problem, some questions came up in connection to your video.

You mention that it's important to leave som unformatted space. Most Linux installs I have tried earlier (e.g. Linux Mint and Ubuntu/Lubuntu) have had as default option to erase all previous data and use the whole disk to create a new partition. Does this mean in this case "joggling blocks around" and load balancing will not work properly?

I found a similar video. In this video the boot flag was set. In Puppy it appears there's no need to set the boot flag. What's the intended functionality of the boot flag, and why is it not needed in Puppy linux?

Again, in that same video swapon is set. Like with the booot flag, it appears in Puppy there's no need to set swapon. What's the intended functionality of swapon, and why is it not needed in Puppy linux?

[bigpup]

The boot flag is a requirement of some computer bios/UEFI boot processes.
It looks for this flag, so it knows the boot loader stuff is on this partition, of the drive.
Some will not identify a drive, as a boot device, if it does not have the boot flag.

Swap is auto set to on in Puppy.
Swapon command not needed.
If during the boot process, there is found a swap file or partition, it will be on, active, and used.

[mikewalsh]

@Kjellinux :-

Mm. Well, the advice about unformatted space on a USB drive is all to do with the way the controller chip reads, writes, and re-allocates data "blocks".

Hard drives don't have this issue. Their controllers work in a totally different way, and 'parts' of a file might be scattered across multiple locations on a disk. However, because of the way the controller & 'read head' read & retrieve a file's associated metadata between them, an HDD can always re-assemble everything as it should be.....HDDs use a 'random write' operation.

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

As I understand it, flash memory works very differently. For argument's sake, say, a data "block" occupies 512 kb of adjacent space. Say your "block" contains 50kb of data, and you want to update it to add another 20kb of data. You would think the controller would simply write another 20kb to it, and you'd carry on, right?

Wrong. Not even close. Definitely no cigar in this case.

Once a "block" of flash memory has been written to, it has to be erased before it can be written to again. So; the controller has to copy that information off to a 'spare' block, while at the same time holding onto the new data you want to add, and erasing the existing block. It then writes the old data back to the current block, at the same time merging the new data with it.... And this is going on thousands of times a second, in different locations all across the NAND flash chip. With me so far?

NAND flash 'cells', which comprise each data block, have a finite number of times that write operations can be performed on them before the physical structure of the cell becomes worn, and doesn't hold charge correctly any more. Read operations, conversely, always number far higher than write operations, due to this erase/re-write cycle; writing, it seems, is more 'stressful' to the physical structure of a cell than a read operation.

NAND flash is far more durable today than in the early days. Number of cycles are probably in the order of thousands of magnitudes greater than they used to be.....but there is STILL a point at which the cell structure begins to break down and fail to function correctly. USB drives & SSDs keep a 'pool' of 'spare' blocks specifically for this 'write-caching' operation, as it's called, but if you fill a drive completely you are definitely making life harder for the controller chip.

Therefore, leaving a small amount of space unformatted just makes life easier for the hardware, and helps everything to run more smoothly. And also helps to prolong your drive's lifespan.

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

I've never, EVER heard of not bothering to set a 'boot flag'. Certainly not where creating a bootable drive is concerned. (A CD wouldn't need this, obviously, because it's already set-up to boot.....in addition to which the ISO9660 file format is read-only anyway).

Where did you see this?

Mike.

[Kjellinux]

@mikewalsh

I've never, EVER heard of not bothering to set a 'boot flag'. Certainly not where creating a bootable drive is concerned. (A CD wouldn't need this, obviously, because it's already set-up to boot.....in addition to which the ISO9660 file format is read-only anyway).

Where did you see this?

Mike.

I just might have seen it in a video in this thread...

[bigpup]

For USB, SSD, SD cards, any drive that is made up of flash memory.
Making partitions, using all of the unallocated space is not going to be any different from not using some of the unallocateed space.
As long as not all of the free space in the partition is not used.
There will always be some unused flash cells usable for load leveling.
Good quality drives will have some amount of cells, that never get seen to be accessed to partition.

Not so much for USB flash drives, but true for good quality ones.
SSDs will always have unused memory cells, even if you fill the drive 100%. It's called over provisioning and it's usually set at 7% or more.
Basically the drive will only show 93% of the memory cells, as available to partition and use.

Good explanation of this over provisioning:
https://www.seagate.com/tech-insights/s ... master-ti/

Just keep some free space never used, if you do not trust, they put enough over provisioning, in the drive.
But, no reason to not make partitions, from all of the unallocated space, the drive internal controller, identifies as being, on it.

some manufacturers reduce the amount of capacity available to the user and set it aside as additional over-provisioning. For example, a manufacturer might reserve 28 out of 128GB and market the resulting configuration as a 100GB SSD with 28% over-provisioning. In actuality, this 28% is in addition to the built-in 7.37%, so it’s good to be aware of how vendors toss these terms around. Users should also consider that an SSD in service is rarely completely full. SSDs take advantage of this unused capacity, dynamically using it as additional over-provisioning.

[rcrsn51]

I've never, EVER heard of not bothering to set a 'boot flag'.

When you put some version of GRUB on the MBR of a hard drive, it has ZERO interest in whether ANY partition is flagged as bootable.

That's because its Stage1 boot code knows where to find its Stage2 code and the corresponding menu.lst file on whatever partition it is located.

But as bigpup has stated, some BIOSes first check to see if a boot flag is set on any partition to decide whether the drive is actually bootable or is just a data drive. Flash drives may sometimes be treated that way - hence the recommendation to set a boot flag on them.

BTW, the concept of a boot flag does not exist in the UEFI framework. The UEFI firmware looks for an ESP partition to start the boot process.