Kolibri - a desktop operating system in under 3 MB

[gadget42]

@pdp8 - enjoy your numerous additions to all the various commentaries across the spectrum here on the forums! keep up the great works!

ps-loved the vde editor!

[nick65go]

Why I am still hunting on KolibriOS?
Because Linux is focused on corporations instead of individual private users. TC should be the most efficient with resources. Lets see what TC shows for using PDF docs. Remember, PDF is PORTABLE Document Format. The more portable, then the smaller tools to use it.

Code: [Select]

qemu-system-i386 -accel kvm -cdrom TC-12.0-K_5.10.3
from Appls, search for "pdf" and we find only two:
epdfview.tcz (size+dep = 19.34 MB, updated on 20/02/29)
flaxpdf.tcz    (size+dep = 12.73 MB, updated on 20/01/07)

Logically we choose the smallest tcz storage on disk, and smallest RAM load, the flaxpdf.tcz

Code: [Select]

tce-load -iw flaxpdf.tcz
in aterm, "du -h /" give us 83.1 MB storage used
in aterm, "sync; sync; free -k" and we see the used RAM= 31,860K (=31MB)
(FYI: we mounted 30 loops of 4KB each, so yeah their consume themself 120 KB, negligible)

If we try with TinyCorePure64-12.0 will be worst (bigger kernel, progs, libs).
Summary: today a minimal FUNCTIONAL linux asks for 31 MB RAM and 81MB HDD storge for using a common standard format PDF.

Hm, it is like instead to use vi_busybox (or nano), we use abiword_gt2/3 (or libreoffice-writer) for text file.Or M$windows loading 1000 services you do not need, but hey it knows better than you what you need.
I did not even discuss about a simple internet browser to see "free"/public HTTPS web-site in year 2022.
But.. it is not TC fault, it is Linux trend toward bloat software, to justify more RAM and CPU purchase.

[Rich]

Hi nick65go
I use the old version 1.1 of  FoxitReader  for PDF files. It's only about 4 MB and depends on  libcups  and  gtk2.
There is a  GetFoxitReader  script I posted that will download and package it into a  .tcz  file:
http://forum.tinycorelinux.net/index.php/topic,23493.0.html

This is a 32 bit application. I don't know of any 64 bit versions.

I have Firefox call FoxitReader when it encounters a PDF file. My only complaint is FoxitReader always defaults to a
fixed size that is built into the program, so now I have a script that starts it using the Resizer extension:
http://forum.tinycorelinux.net/index.php/topic,25125.msg160223.html#msg160223

The script works even if the PDFs filename is unquoted and has spaces in it. I've attached the script to this post.

[nick65go]

Hi Rich, thanks for the options (foxitReader)
In KolibriOS they have ymupdf which run in max 5 (?) MB RAM (kernel included).
but Archlinux or AlpineLinux (which others consider "leaders" in linux race), have just the executable / library of 35+MB. Then you add the full dependencies and the kernel,
https://archlinux.org/packages/community/x86_64/mupdf/
https://pkgs.alpinelinux.org/package/edge/community/x86_64/mupdf

My remarks were about how bigger have become "new" versions, without essential improvements.

[Rich]

Hi nick65go

... My remarks were about how bigger have become "new" versions, without essential improvements.

Yes, I realized that. I just wanted to point out there is a very capable lightweight viewer that is visually pleasing
still available. I run it under TC10 as well as TC4.

[PDP-8]

Nick - one man's bloat is another man's usability.

It gets philosophical at some point, and certainly no corporatation is going to look to TC as an example to follow.  For one thing, it is a small /core/, but one has the freedom to turn it into a total monster emulating them if they want to.

So it is merely a personal choice.  But what about other small brothers like Slitaz, Porteus etc etc?  Are they bloated because Slitaz in X form is 50mb distributed - which you can also bloat up to your liking?  Or Porteus comes in at a whopping 300mb or so distributed?  But by the time you beef up TC, it *TOO* is 300mb or so on disk or more with many of the same features?  (albeit with different underlying technical designs).

Thing is, and here I go again - what did our Unix forefathers do when larger amounts of ram and storage became available every few years or so?  They jumped on it!  But yes, they decried how bloated the CSRG / BSD userland had become, and railed at such wastefully bloated things like cat-v, head/tail, and TCP/IP of sockets vs streams had become.

Just saying - tiny and efficient vs usability is a personal decision, and sometimes an arbitrary limit to one person - is handcuffs to another.

Remember that unproven urban-legend that said Gates once remarked that 640k should be enough for everybody?  And of course the ASM guys saying that "he who can't program in 64k can't do so in 640".

Same deal.  It all depends on the users choice, which is more philosophical / societal / user skillset, rather than a technical solution.

[xor]

It was a dream, but it's coming true!

"Intel Releases ControlFlag 1.0 For AI-Driven Detection Of Bugs Within C Code"

https://www.phoronix.com/scan.php?page=news_item&px=Intel-ControlFlag-1.0

artificial intelligence will one day make dreams come true.

[xor]

MenuetOS 900 kb !

18.02.2022 M64 1.40.40 released - Updates, bugfixes and improvements

http://menuetos.net/

https://en.wikipedia.org/wiki/MenuetOS