Tiny Core Linux
Off-Topic => Off-Topic - Tiny Core Lounge => Topic started by: hiro on May 01, 2014, 06:02:12 PM
-
http://morpheus.2f30.org/
It shares quite some concepts with tinycorelinux.
Like tc they have a curious way of doing package management (aufs).
Haven't tried it yet, but it's for sure inspirational.
-
Sounds interesting, but it says "Package management using mount overlays (aufs)", and that scared me off. No more union fs for me.
-
Statically linked apps are not my favourite either.
-
Sounds interesting, but it says "Package management using mount overlays (aufs)", and that scared me off. No more union fs for me.
Package management is always scary, I know tinycore decided back then that the unionfs route would be too complicated. But I'd be happy for the morpheus people if they can utilize it in a stable way. I wonder also if in practice there are other benefits over linking.
About statically linked apps I think you should read their justifications and look at how well it works in plan9 (look at how fast the whole OS compiles and how small the binaries are. also where union directories make name space seperation work which amongst many other things allows you to make very simple and useful security abstractions, also I like how it completely eliminates any need for PATH environment variables, as bins just get bound into the one and only /bin)
I'm probably not the best to explain any of these concepts so he're some pointers, I really enjoyed reading this stuff:
http://man2.aiju.de/1/intro (i.e. grep for union dir in the name spaces section)
http://plan9.bell-labs.com/sys/doc/names.html
http://harmful.cat-v.org/software/dynamic-linking/
http://wayback.archive.org/web/20090525150626/http://blog.garbe.us/2008/02/08/01_Static_linking/
-
There is a room for statically linked applications. I see benefits for example on Windows to have a portable application which can be used over wide range of Windows versions, do not require stupid installation program, etc. Where I can can me mostly sure, it will work at a customer (end user). This can work on Linux too, including closed source (commercial) applications. Take Go, it creates statically linked executable.
However on the system side it can be a nightmare. Imagine a security bug for example in your SSH library. When you have a fix in shared lib environment, you must update just the SSH library. In a statically linked you must rebuild all apps using it. Also using shared libs significantly reduce the overall system size.
-
When you have a fix in shared lib environment, you must update just the SSH library. In a statically linked you must rebuild all apps using it.
If you compile everything yourself then it won't create much more pain than what you already have.
And most people update way too often anyways (just features or useless changes that often bring new bugs, new incompatibilities and new security problems). In other words: I value quality over quantity of updates.
If you kept it to just security critical stuff there isn't that much to update anyways, so you can actually save time even compared to binary packages.
And most people use binaries anways, they don't need to recompile anything EVER.
Also using shared libs significantly reduce the overall system size.
Dynamic linking has considerable overhead.
There are some huge libraries that for the biggest part of them aren't even used by any installed app. If we were to link our apps just against the subset of functions they actually use we might see overall system space savings.
The only thing I know supporting your point would be GTK and glib. They are a huge problem, but I don't think hiding that with dynamic linking is worth anything or anyways working well at all.
Security-wise dynamic linking is the real nightmare. It creates so much complexity that nobody knows how to handle it. Just look at the examples linked on the pages in my other post.
-
Dynamic linking has considerable overhead.
There are some huge libraries that for the biggest part of them aren't even used by any installed app. If we were to link our apps just against the subset of functions they actually use we might see overall system space savings.
There are tools that analyze a complete system, and then strip the unused symbols out of the shared libs. If you're going to create a static (heh) system, one of those would be useful.
Go
Nice example to the sizes involved, a hello world in Go is 900kb stripped.
-
Well, go is a language that has deliberately not been optimized for binary size. The same people were involved in plan9 and all the statically compiled binaries on there are incredibly small.
I don't think huge binaries are nice, but small binaries are also possible with static linking.
Also just learn to use simpler, smaller libraries instead of bolting on streamlined wrappings.
-
Nice example to the sizes involved, a hello world in Go is 900kb stripped.
Just built a hello word in TC 5.x with Go 1.2.1 Result is 1.8M unstripped, 1.2M stripped
-
I used 1.0.2. Increasing bloat in just two minor versions :P