Possible space savers for base version if/when iso no longer fits on CD

[Moderator BobC]

To save a few mb remove:
vim-tiny
vim-common
nano (requires changing streamlight-antix to use another editor, generic would be best)

To save more mb remove:
geany (requires changing the cc options to use a generic multi file editor, and loading a smaller editor, like medit, so all config files can be opened in tabs easily)
geany-common

Nothing in antiX-19_386-base requires the vim programs anymore!

• This topic was modified 3 years, 6 months ago by BobC.

[Anonymous]

Helpful

Up

0

::

BobC, check out “mousepad” editor. It is now tabbed. Also, it has both lighter dependencies and lesser memory overhead than “medit”.

One shocking//weird detail that I discovered today:
the the buster “feh” package it’s installed package is only “is only 357kb” …
…but now depends on “yudit-common” which is 9.4Mb !
(yudit-common provides the guts of “yudit”, a unicode text editor which is not pre-installed)

git clone https://salsa.debian.org/debian-phototools-team/feh
cd feh
grep -inr ‘yudit’

src/feh.h:95:#define DEFAULT_FONT "yudit/11"
src/feh.h:96:#define DEFAULT_MENU_FONT "yudit/10"
src/feh.h:97:#define DEFAULT_FONT_BIG "yudit/12"
src/feh.h:98:#define DEFAULT_FONT_TITLE "yudit/14"
Binary file share/fonts/yudit.ttf matches
man/feh.pre:546:.Pq truetype, with size, like Qq yudit/12
debian/feh.links:2:usr/share/yudit/fonts/yudit.ttf	usr/share/feh/fonts/yudit.ttf
debian/control:25:         yudit-common
debian/changelog:85:  * Use yudit.ttf from yudit-common package
ChangeLog:1330:  * stick in yudit.ttf. it's not as pretty, but it is, apparently, DFSG

[Moderator BobC]

Helpful

Up

0

::

Skidoo, yes you are correct, and could probably replace leafpad at the same time as well. Not a lot of savings individually, but enough to help keep other critical programs on the CD when things get too tight. I never guessed that mousepad did tabs.

I also noticed the feh requirement, but yudit isn’t something I’m familiar with. I wonder if mirage or graphicsmagick or some other lighter package could do the wallpaper manipulations?

[Anonymous]

Helpful

Up

0

::

As a followup to kenzo’s post (idunno which language, or languages plural kenzo would keep)
I tested “whatif remove extraneous locales and such from antiX19 base”.
(this test involved the removal of ZERO pre-installed packages)

================================

browse to /usr/share/locale/ and not that it contains 199Mb files

sudo apt update
sudo dpkg-reconfigure locales (on test machine, I kept only en_US.UTF8)
sudo install localepurge (skim the list, click OK, answer Yes to “Use dpkg –path-exclude”)
sudo install bleachbit

sudo bleachbit —-}
…click OK to close the autopopup “preferences” dialog
…find and tick “Localizations” in left pane, click OK to dismiss autopopup dialog
…click the TrashCan bleachbit toolbar icon, click “Delete” button in the confirmation dialogbox
noted: bleachbit reported (in my test) Disk space recovered 210Mb
…exit bleachbit

sudo apt purge bleachbit

browse to /usr/share/locale/
noted (in my test) that bleachbit missed 8.7 Mb files here
On the test machine, I nixed all here EXCEPT:
/usr/share/locale/en/
/usr/share/locale/en_US/
/usr/share/locale/[[[symlink to]]]locale.alias
( and now /usr/share/locale/* occupies only 212Kb )

2.5Mb /usr/share/gnome/help/gparted/
(on an English-only system) delete all items here except the subdir named “C” …leaves 215kb
.
1.5Mb /usr/share/gnome/help/synaptic/ {——— if synaptic package is currently installed
Similarly, (on an English-only system) delete all items here except the subdir named “C” …leaves 480kb
.
Note: As additional programs are installed, locale-specific files may accumulate here (localepurge seems unaware of these)

1.4Mb (on an English-only machine, these are never utilized)
sudo rm /usr/share/perl/5.28.1/Unicode/Locale/*
sudo rm /usr/share/perl/5.28.1/Unicode/CJK/*

====================

Next, I used “ncdu” to quickly look for fluffernutter items, and nixed:

2.8Mb
sudo apt purge breeze-snow-cursor-theme-antix

deleted these:
2.0Mb /usr/share/wallpaper/PrettyPink.png
130Kb /usr/share/wallpaper/auditorio-de-tenerife2.jpg
150Kb /usr/share/wallpaper/login/auditorio-de-tenerife2.jpg

4.8Mb /usr/share/icons/Adwaita/256×256/*
2.3Mb /usr/share/icons/Adwaita/512×512/*
704Kb /usr/share/icons/Adwaita//96×96/*

805Kb /usr/share/icons/hicolor/512×512/cmst.png
384Kb /usr/share/icons/hicolor/384×384/cmst.png

then, to guard against pkg upgrades causing unwanted reinstallation of the above:

sudo apt-mark hold adwaita-icon-theme
sudo apt-mark hold papirus-antix
sudo apt-mark hold breeze-snow-cursor-theme-antix (idunno, would a dist-upgrade operation attempt to reinstall it?)
sudo apt-mark hold artwork19-antix

===========================

sudo apt install synaptic (its installation is counterproductive for this, but oh well)
sudo updatedb (freshens the db index employed by the “locate” command)

after the above, launching iso-snapshot reported Space Used: 1.9G (w/ original, was reported as 2.1G)
click Next, choose xz compression scheme, click Next, click OK in the popup dialogbox
. . .
the resulting ISO file is 653.7Mb 685768704 bytes
.
from original antiX-19_386-base.iso 697.0Mb 730857472 bytes
(reduction of 6.3% or 44Mb)

counted estimate, from my notes above + bleachbit output ~= 259M
(IOW, approx 250Mb less overhead during a toram liveboot session)

[Anonymous]

Helpful

Up

0

::

off-the-cuff (not recommending, just mentioning) I would probably also apt purge
8.5Mb arc-theme
4.0Mb newsboat

I would also install “ranger” (cli file manager) (862kb) and “lxterminal” (588kb)

locate .pyc
It is safe to delete any/all .pyc files; upon firstrun of their associated program, python will individually recreate these, as needed.
Because they do not cumulatively occupy many Mb of storage space, and because their recreated copies will occupy space in the rootfs persist file…

(if running live persistence, and your persist exclude file lacks a pattern to match .pyc)

…I did not chase down the .pyc files. In past tests IIRC they occupied 10-12Mb

[Moderator BobC]

Helpful

Up

0

::

Yes, I don’t use arc-theme either. Removed. Ditto for Newsboat.

I added ranger. Not too big. I will try it. Midnight commander is sometimes too complex. It just has quirks compared to the old Norton Commander I loved. I use mc a lot in spite of its faults.

Something I found tonight was XFE, and old style X-Windows file manager that seems to work a lot like what I am comfy with. Old is not bad in my book, if functional, and XFE did my configurable search displaying large or small thumbnails of the results and 2 or 3 pane display, which to me, is great.

Thanks for your inputs.

Maybe we should be thinking about doing something like Puppy where they strip out “stuff” when things are loaded. I look at the installed list and find what appears to be a lot of that. It might be nice to just not load it in the first place, and be able to include it when its actually useful.

[Forum Admin BitJam]

Helpful

Up

0

::

BobC wrote:

To save a few mb remove:
vim-tiny

You lost me at removing vim-tiny. Hobbling my development to save 600K is a really bad deal IMO. Also, many other people rely on some form of vi being available. It has kept people away, most likely the sort of people it would be useful to have on board This really seems penny-wise and pound-foolish to me.

Context is worth 80 IQ points -- Alan Kay

[Member fatmac]

Helpful

Up

0

::

I’m pretty sure the easiest way to make ‘base’ fit a CD still is to swap dillo for firefox, (which can be then be added after installation).

Lightweight file managers, there used to be mc-lite, which was quite useful, (but I don’t think it is maintained), also there is vifm – https://vifm.info/

Whilst looking up one file manager, I came across this – https://www.tecmint.com/linux-terminal-file-managers/

Linux (& BSD) since 1999

[Moderator BobC]

Helpful

Up

0

::

No problem bitjam. Keep in mind we are talking about how to keep the 32 bit version fitting on a CD rom, not talking about the 64 bit version or full version.

But anyway, with regards to vim-tiny, if it’s for you, its worth keeping 🙂

For me, I open it and never figure it out, and have to kill it or get out an old Unix book, lol.

[Anonymous]

Helpful

Up

0

::

FYI, the dependency on pkg “yudit-common” is bogus, is unwarranted.
The upstream source (as well as the debian feh package) already provides a copy of the yudit.ttf file.
Debian’s “team” apparently felt compelled to bundle (depend on) that other package because feh source lacks a copyright file and/or LICENSE file for yudit.ttf

(tested) removed the debian/control Depends: yudit-common declaration
rebuilt and installed the package, purged yudit-common (9.4Mb), and feh still runs without errors.

[Forum Admin BitJam]

Helpful

Up

0

::

BobC wrote:

No problem bitjam. Keep in mind we are talking about how to keep the 32 bit version fitting on a CD rom, not talking about the 64 bit version or full version.

But anyway, with regards to vim-tiny, if it’s for you, its worth keeping

Thanks for understanding! Since I use vim for development I would have to change gears when working on the live system (which I do a lot). Having vim-tiny has really helped. Also, we had received some rather strong complaints about the lack of an vi-like editor which many people (probably old-farts like me) consider to be standard and expected on any Unix-like system.

BTW: there are several editors in the live initrd. The “e3” editor takes only 13K and it has symlinks to change it’s personality. I tried to attach a tarball with e3 and its symlinks but it seems that attaching anything useful is not allowed for security reasons. You can get it from the bin directory of my live-initrd repo.

Context is worth 80 IQ points -- Alan Kay

[Moderator BobC]

Helpful

Up

0

::

Yeah I know what its like to try to fix things using unfamiliar tools, and wouldn’t wish it on anyone.

I do like Geany myself, but would rather find a way to keep a browser that normal people would find familiar as well. I am much more likely to be able to get Geany loaded than normal people would be trying to run Dillo and then getting Firefox installed.

[Forum Admin BitJam]

Helpful

Up

0

::

We could go 1990s retro and make a 2nd cd-sized iso file that just has a bunch of .deb packages on it.

It’s a real struggle. One of the reasons we use our own live system is we’ve been able to keep it small, under 5 Meg. But Grub makes up for this by consuming 13 Meg which blows my mind.

For machines that have a usb port but only boot from cd, you can use an antiX cd to boot from an antiX live-usb (assuming they use the same kernel). With the fehlix rescue system we added to grub on the live system (its not the thing gobbling up space) even the same-kernel restriction could be lifted, if it hasn’t already. I’ll ask him about this.

The cd-size restriction on one hand and the bloat bloat bloat (and legitimate growth) of software on the other puts us between a rock and a hard place. I hope we can make use of creative solutions to get around these restrictions and try to get the solutions well publicized.

Context is worth 80 IQ points -- Alan Kay

[Forum Admin BitJam]

Helpful

Up

0

::

I think we could save about 8.8 MiB if we remove the UEFI booting option from the 32-bit base system.

Even while keeping the UEFI option we could save about 1 MiB by making a change in live-usb-maker to take advantage of the /boot/grub/efi.img file.

Context is worth 80 IQ points -- Alan Kay

[Member mroot]

Helpful

Up

0

::

I kinda like the idea of the “1990s retro” 2nd cd-rom. It would allow more flexibility and maximize the number of users that would find the iso usable for their needs.

• This reply was modified 3 years, 6 months ago by mroot.
• This reply was modified 3 years, 6 months ago by mroot.
• This reply was modified 3 years, 6 months ago by mroot.

[Author]

Posts