Tiny Core Linux
Off-Topic => Off-Topic - Tiny Tux's Corner => Topic started by: bmarkus on August 31, 2009, 03:46:09 AM
-
Size is a frequent discussion topic here, in terms of the system, RAM usage, etc. There is in interesting article about
Kolibri OS at Distrowatch (http://distrowatch.com/weekly.php?issue=20090831#feature)
While Kolibri itself is interesting, TC is used as a reference by the author of article:
"But what if I told you that I was recently running a modern operating system that requires about 5 MB of disk space and about 10 MB of RAM? That sounds like a stretch, doesn't it, even for Tiny Core Linux?"
;)
-
Previous topic about Kolibri (before the DW article though):
http://forum.tinycorelinux.net/index.php?topic=1189.0
-
There may be open source operating systems (e.g. BSD) that in some theoretical sense are "better" than Linux. However, nobody seems to have taken the trouble to make a distro of any of them that is as light and flexible as TCL. When somebody does I'll give them another look.
-
the review is interesting, and i can imagine that tc/mc could be reduced to less than 5 MB with much more flexibility than kolibri and much more usability. tc/mc would be then unexampled.
-
Necromacy of this thread, abandoned from 2009, so there are 12 years without a word about kolibri development.
Today Kolibri has English text (menu, docs) or Spanish etc; and google translate is good enough for rusian to english. Its initial mising of appls was corrected, today having a lot of drivers and applications.
http://wiki.kolibrios.org/wiki/Hardware_Support
Even it started to focus on old-windows appls by using wine.
It seams to be good to play with it on / off-line. Especaily for Very-low RAM.
http://websvn.kolibrios.org/listing.php?repname=Kolibri+OS&
-
Just a small summary for KolibriOS, because is no point to make a blog on a TC forum.
Kolibri can boot from BIOS, but also from UEFI (without sh*t secureboot).
It has drivers for REAL devices (acpi, ahci,, VESA, atikms, i915, etc).
atikms = Video ATI KMS, R100-R600, Evergreen, Northern Islands, Southern Islands
i915 = Video Intel i915, all PCI Express video cores from i915 utill Skylake
I do not have real vinatge/old devices , so I used QEMU, for which Kolbri has video (VESA3 and VMware SGA II), many network NICs, audio (AC97 and intel-HDA), etc.
From the few hours that I used it, here are few Progs Associations extracted from KFAR.ini (File manager):
/sys/network/WebView -> htm, html, mht, docx, url
/kolibrios/media/updf -> pdf
/sys/table -> csv
/sys/media/pixie -> wav, mp3, xm
/kolibrios/media/fplay_run -> avi, mpg, mp4, mpeg, mov, flv, wmv, vob, mkv, 3gp, webm
/sys/media/kiv -> jpg, jpeg, jpe, gif, ico, bmp, png, cur, pcx, pbm, pgm, pnm,ppm, tif, tiff, wbmp, xcf
/sys/TinyPad -> ams, inc
/sys/develop/cedit -> ini, c, cpp, h, pas, lua, ob07
/sys/RtfRead -> rft
/sys/Quark -> txt
These prove the capabilities for web, image, audio, video, pdf, many compilers, all already built inside it.
Have fun with it off-line. HTTP is OK, HTTPS not yet (/never).
bonus: http://wiki.kolibrios.org/wiki/File:Kernel_includes.png (http://wiki.kolibrios.org/wiki/File:Kernel_includes.png)
-
Question : so why does TCL consume so much RAM space!?
-
Kolibri would boot on the old amd k6-2 166mhz machine but it complained about the processor and the shell wouldn't run.
Tried it on a 12-core xeon workstation and it booted to the main desktop but again complained about the processor.
Decided to shoot for some middle-ground and grabbed a q6600 core2quad machine. Booted and ran fine.
(did need to grab a pci lan card as kolibri didn't want to play nice with the onboard nic)
Definitely not a web-surfing system but it would probably be fine for gopher and gemini.
the games are addicting...shesh...lol...
-
With any program (except some games) less than 1 MB compiled, or a kernel.* less than 200 KB --> anything can be re-build from scratch. So with a little study (actually a lot of learning) the FASM (or tinyC, C--, lua, etc) will make wonders in minutes.
But I am not (yet) keen to learn (again) ASM language, to understand and change the few parameters from .inc /.asm etc. to customize programs / drivers. Anyway, will be fun in next years (or rainy days). Expeciaily because it started to have emulators/ compilers for other architecture (Linux, arm7).
-
The reason it is so small is that it is written entirely in assembly language. Definitely NOT the unix way!
Which means it is non-portable and machine specific. It is how operating systems were written in the 60's. Which means it is locked in time and dies with the hardware it was written for.
Our ATT unix forefathers, nay the earlier MULTICS operating system got away from that and broke ground by being written in a high-level language, PL/I. Unix followed suit, and instead of PL/I, a transitionary period followed with human-readable languages like BCPL, B, and eventually C.
Contrast this to another OS written at the time, the ITS timesharing system, which was also written entirely in assembly for the PDP6/PDP10 mainframes. Greenblatt and RMS were maintainers among others. Where is it now? DEAD, because in assembly, there is no path forward unless you want total rewrites every time a new hardware environment is introduced.
Our forefathers, Doug Mcilroy, Ken Thompson and many others at ATT broke that ridiculously unmaintainable situation by writing systems software in a higher level language.
This small tradeoff in a larger size with human-readable languages, means that the system has a chance to be portable to other architectures, improved, and maintained well into the future.
So even back then, a small tradeoff in size vs real-world sustainability was realized.
Kolibri is a throwback to the 60's niche-hack and definitely not the unix way.
-
Unix way, or not, maybe is not important for some people. It is a free world out there, each on his way.
Someone need just an optimized engine for his car. And not a general engine for any airplane or submarine U-boat. Thanks for the history. But Apple with its dedicated devices (restricted components) has won the market, same as google. Even I dislike both, but I use them. Mais c'est la vie, toujours bâtard.
-
Yeah, sorry about that. I don't mean to come off like some energy-drink fueled history teacher. Just can't help it when I see complaints of size.
There's a time and place for it, but systems programming isn't one of them. However, you did bring back memories of an assembly program I
absolutely *loved* back in my dos days: Eric Meyer's VDE editor.
Being all assembly, it smoked! What really blows my mind is that after a TWENTY ONE year haitus, it has returned!
https://sites.google.com/site/vdeeditor/Home/vde-files
If one is still using ms-dos, freedos, or maybe even an older version of windows on ancient hardware - this editor is for you! Columnar editing in
something this small and fast blew my mind, and I whipped out the shareware fee back when it wasn't free.
Caution: if you like this, you may be able to transition to the portable JOE editor, which can be called by either joe (native keybdindings), jstar (wordstar)
or jpico (pico / nano) keybindings.
-
Considering that ASM has left its place to LLVM, a portable language !
What are the chances of this project coming back to life!?
The reason it is so small is that it is written entirely in assembly language. Definitely NOT the unix way!
Which means it is non-portable and machine specific. It is how operating systems were written in the 60's. Which means it is locked in time and dies with the hardware it was written for.
Our ATT unix forefathers, nay the earlier MULTICS operating system got away from that and broke ground by being written in a high-level language, PL/I. Unix followed suit, and instead of PL/I, a transitionary period followed with human-readable languages like BCPL, B, and eventually C.
Contrast this to another OS written at the time, the ITS timesharing system, which was also written entirely in assembly for the PDP6/PDP10 mainframes. Greenblatt and RMS were maintainers among others. Where is it now? DEAD, because in assembly, there is no path forward unless you want total rewrites every time a new hardware environment is introduced.
Our forefathers, Doug Mcilroy, Ken Thompson and many others at ATT broke that ridiculously unmaintainable situation by writing systems software in a higher level language.
This small tradeoff in a larger size with human-readable languages, means that the system has a chance to be portable to other architectures, improved, and maintained well into the future.
So even back then, a small tradeoff in size vs real-world sustainability was realized.
Kolibri is a throwback to the 60's niche-hack and definitely not the unix way.
-
@PDP-8: I tested a "distro" (KolibriOS), not made by me, and I shared my opinion about few technical things about it. I do not advertise it, because I have no gain from this and I did not contributed to it.
The tempting goals (for me) from Kolibri are its speed and size. For QEMU (secured environment) with standardized "devices" (video, audio, network, fdd / hdd / cdrom / usb) it makes sens (same as Apple made the decision to have strict specialized /optimized devices).
PS: I dislike when someone blog here, hijacking the subject. There are other ways "to teach others your way of doing things". Especially when in the last two post you did nothing constructive about Kolibri. I understand (and disagree with) your opinion about some languages (ASM) and their bright future (as seen by you). It is no need to write another 100 posts to repeat the same ideas. Or maybe you like to have the last word / impression in the forum. Why don't you open an off-topic for yourself about what is important to you, and live this alone?
-
artificial intelligence will one day make dreams come true. :D
-
@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!
-
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.
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
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.
-
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.
-
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://archlinux.org/packages/community/x86_64/mupdf/)
https://pkgs.alpinelinux.org/package/edge/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.
-
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.
-
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.
-
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. :D
-
MenuetOS 900 kb ! :)
18.02.2022 M64 1.40.40 released - Updates, bugfixes and improvements
http://menuetos.net/
https://en.wikipedia.org/wiki/MenuetOS