WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: interesting competition  (Read 3571 times)

Offline hiro

  • Hero Member
  • *****
  • Posts: 1228
interesting competition
« on: May 01, 2014, 03: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.

Offline Lee

  • Hero Member
  • *****
  • Posts: 645
    • My Core wiki user page
Re: interesting competition
« Reply #1 on: May 01, 2014, 11:49:15 PM »
Sounds interesting, but it says "Package management using mount overlays (aufs)", and that scared me off.  No more union fs for me.

32 bit core4.7.7, Xprogs, Xorg-7.6, wbar, jwm  |  - Testing -
PPR, data persistence through filetool.sh          |  32 bit core 8.0 alpha 1
USB Flash drive, one partition, ext2, grub4dos  | Otherwise similar

Offline bmarkus

  • Administrator
  • Hero Member
  • *****
  • Posts: 7183
    • My Community Forum
Re: interesting competition
« Reply #2 on: May 02, 2014, 01:27:33 AM »
Statically linked apps are not my favourite either.
Béla
Ham Radio callsign: HA5DI

"Amateur Radio: The First Technology-Based Social Network."

Offline hiro

  • Hero Member
  • *****
  • Posts: 1228
Re: interesting competition
« Reply #3 on: May 03, 2014, 11:16:56 AM »
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/
« Last Edit: May 03, 2014, 01:13:38 PM by hiro »

Offline bmarkus

  • Administrator
  • Hero Member
  • *****
  • Posts: 7183
    • My Community Forum
Re: interesting competition
« Reply #4 on: May 03, 2014, 11:52:58 AM »
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.

Béla
Ham Radio callsign: HA5DI

"Amateur Radio: The First Technology-Based Social Network."

Offline hiro

  • Hero Member
  • *****
  • Posts: 1228
Re: interesting competition
« Reply #5 on: May 03, 2014, 02:41:02 PM »
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.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10992
Re: interesting competition
« Reply #6 on: May 04, 2014, 02:06:47 AM »
Quote from: hiro
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.

Quote
Go

Nice example to the sizes involved, a hello world in Go is 900kb stripped.
The only barriers that can stop you are the ones you create yourself.

Offline hiro

  • Hero Member
  • *****
  • Posts: 1228
Re: interesting competition
« Reply #7 on: May 04, 2014, 02:53:37 AM »
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.

Offline bmarkus

  • Administrator
  • Hero Member
  • *****
  • Posts: 7183
    • My Community Forum
Re: interesting competition
« Reply #8 on: May 05, 2014, 12:25:45 AM »
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
Béla
Ham Radio callsign: HA5DI

"Amateur Radio: The First Technology-Based Social Network."

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10992
Re: interesting competition
« Reply #9 on: May 05, 2014, 01:06:25 AM »
I used 1.0.2. Increasing bloat in just two minor versions :P
The only barriers that can stop you are the ones you create yourself.