WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: [mpd] micro is not micro  (Read 3950 times)

Offline hiro

  • Hero Member
  • *****
  • Posts: 1217
[mpd] micro is not micro
« on: October 21, 2010, 09:54:16 AM »
Hi, today I tried to setup a very basic install on my embedded device. My only wanted extension: mpd
tce-load downloads what feels like a debian of extensions which in my mind is a complete waste of space.
I only use a 32mb DOM for storage and don't it to get full (the reason for using microcore).
I'm now going to use the old tc 2.1, which had less bloated extensions.

We don't need extensions if every extension depends on everything but the kitchen sink.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: [mpd] micro is not micro
« Reply #1 on: October 21, 2010, 10:37:30 AM »
It's true the current mpd.tcz has just about everything enabled. IIRC the consensus was to make a separate -minimal mpd extension.

edit: ref http://forum.tinycorelinux.net/index.php?topic=7295.0
The only barriers that can stop you are the ones you create yourself.

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3857
Re: [mpd] micro is not micro
« Reply #2 on: October 21, 2010, 11:42:14 AM »
~25 MBb is a lot if storage available is 32Mb - whicy I could guess that it's practically less, usually storage space being calculated in decimal rather than binary terms, plus space needed by the file system (format).

No idea what your purpose of using mpd is, but did you look into possible alternatives to achieve your goals?
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline hiro

  • Hero Member
  • *****
  • Posts: 1217
Re: [mpd] micro is not micro
« Reply #3 on: October 21, 2010, 12:18:44 PM »
No idea what your purpose of using mpd is, but did you look into possible alternatives to achieve your goals?

Like I said, I'm back to using tc 2.1 now. And I'm of course using it to listen to music.

Offline hiro

  • Hero Member
  • *****
  • Posts: 1217
Re: [mpd] micro is not micro
« Reply #4 on: October 21, 2010, 12:22:17 PM »
It's true the current mpd.tcz has just about everything enabled. IIRC the consensus was to make a separate -minimal mpd extension.

edit: ref http://forum.tinycorelinux.net/index.php?topic=7295.0

Perhaps you could make the old version mpd-minimal? I would compile it again, but I don't really see the need...

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: [mpd] micro is not micro
« Reply #5 on: October 21, 2010, 12:30:39 PM »
Perhaps you could make the old version mpd-minimal? I would compile it again, but I don't really see the need...

That would be an ok interim solution, until someone submits a native -minimal for 3.x. Ok, copied the 2.x mpd to 3.x as -minimal.
The only barriers that can stop you are the ones you create yourself.

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3857
Re: [mpd] micro is not micro
« Reply #6 on: October 21, 2010, 02:08:03 PM »
No idea what your purpose of using mpd is, but did you look into possible alternatives to achieve your goals?

Like I said, I'm back to using tc 2.1 now. And I'm of course using it to listen to music.

Umm, that listening to music is involved somehow is implied, but for which reason exactly you need mpd for that task?
And where is the music stored? (as you say you have only 32MB of storage)
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline gutmensch

  • Administrator
  • Hero Member
  • *****
  • Posts: 605
  • I can make it disappear, have no fear!
    • remembrance blog
Re: [mpd] micro is not micro
« Reply #7 on: October 21, 2010, 02:15:04 PM »
Apart from building a minimal version it would surely be an improvement if all dependencies (not to say extensions ;) were strictly separated by lib, bin and dev. mpd doesn't need a lame en- or decoder or dbus static libs or libtool archives, just the libs. Same for fluidsynth, flac and so on. It would be good to have some script checking the repo for unstripped versions, too (I guess there are some). Overall from a quick glance I'd say it's definitely possible to minimize the dependency size by about 30% to 40%...

How about an extension auditing (auto generated) wiki page, which states extensions to be reworked?
If I seem unduly clear to you, you must have misunderstood what I said. (Alan Greenspan)

Offline hiro

  • Hero Member
  • *****
  • Posts: 1217
Re: [mpd] micro is not micro
« Reply #8 on: October 21, 2010, 06:44:17 PM »
All my music is stored in google mail.
If I didn't have mpd I would write some sh scripts for the same task, but as it runs very stable here and does everything I need I simply enjoy the music instead ;D
« Last Edit: October 21, 2010, 06:47:38 PM by hiro »

Offline Jason W

  • Administrator
  • Hero Member
  • *****
  • Posts: 9730
Re: [mpd] micro is not micro
« Reply #9 on: October 22, 2010, 01:45:28 PM »
As for the scripted checking and stripping of extension contents, there is one concern I see.  "strip -g", which is what we use on libraries, leaves the file listed as "unstripped" when checked with the file command.  That would make for a lot of unneeded stripping of already stripped libs, though I don't know if that would cause an issue.   Also, some things like grub2 will not function if you strip it's files, though I am not sure if there are other packages like it.

I guess the relevent files could be copied, stripped, and then compared to the original to see if there was an md5 or size difference to determine if "strip -g" was already used on them.  But affecting extension contents without a reasonable means of testing the results makes me a little leery of it though.