Streamlining image compiled from source

Hey, I’m try to create a Haiku image, compiled from source that is without the various non essential applications, documentation and demo packages. Is there a Jam flag or a buildconfig option that might allow me to do this? Also, i highly doubt there is at this stage, but is there a way to compile it without the debug symbols.

The current image size is around 180mb i wouldn’t mind getting that down to 100/120 or less if i can. My haiku kiosk image is going to be stored on an network attached storage so i am trying to strip down the image to the bare bones to move it around more quickly and assume the least possible amount of space.

For included optional packages you should use your own /build/jam/UserBuildConfig. If you mean to strip down the included system software (e.g. shell commands, apps, prefs, libs, servers etc.) it’s probably easiest to just prune build/jam/HaikuImage.
Be aware however, that by not including all these basics, you are creating an incompatible Haiku derivate/distribution. Once you don’t just play around with that yourself but “go public”, you’ll have to think about changes of the Haiku branding (see trademarks etc. at http://haiku-inc.org).

Regards,
Humdinger

Ah ha i knew this would rear its ugly head, if my distro where “incompatible” with haiku, then i would still be able to release it without any licensing issues. the Haiku Inc choice of wording to describe the compatibility levels make it seem illegal to release an incompatible distro. its not. Its MIT licensed after all. I could remove all the GPL components, and replace the desktop with a picture of a giant slong and release it a SlongOS (Bit of a crude example but you get me) Thankfully however i have no plans on releasing it, its just a Kiosk OS for testing on a few machines and the like.

Thanks for the advice, ill look into doing a manual purge now. Ill see how small i can get the build and get back to you. :slight_smile:

Can you cite the passage declaring incompatible distributions illegal? As far as I can see, only using the name Haiku and its logo is limited to meeting this kind of requirement. Of course the code itself is MIT licensed and you can do with it whatever you want. Just not under the name/logo “Haiku”. Pretty sensible.

Regards,
Humdinger

Oh right sorry, i thought you meant that i had to adhere to the compatibly guidelines in order to legally release a distribution based on Haiku. My bad.

I added some visual emphasis to Trademarks - Haiku, Inc.

Brilliant, that will clear it up for anyone who’s in doubt.

I noticed when i was looking through the source that there appeared to be a driver for the Btrfs FS. Would it be possible to boot haiku off of a BtrFS partition or is that only for mounting of a Btrfs filesystem? I would be interested to do some basic benchmarking between BFS and Btrfs on Haiku

The btrfs is read-only accessible, at the moment.

Though, the OverlayFS might be usable for doing tests on non-bfs volumes. For example, the OverlayFS is used when booting Haiku off ISO (@alpha-cd for example)

i would really love to see Btrfs as the default FS with LZO compression. It would give Haiku a sizable performance boost (not like it needs it though)

Well, btrfs could be more native and haiku could utilize that as a optional file system. Also there is a GSOC ZFS project going this year which again should add sizeable storage capacity IIRC as well as a few other features. 

Theres no reason haiku could not support more filesystems in reality but the dev's spent alot of effort to make BFS very workable in haiku. I would imagine all these files systems could be run alongside one another once properly implemented.

I can’t fault BFS, but the option would be great. Is it not just a case of porting the BSD version of Btrfs over to Haiku? I run ext4, XFS, ReiserFS and Btrfs on my computers and BtrFS is noticeably better in terms of I/O performance.

ZFS will add features that would be required if Haiku where a server orientated OS but its not at all. It seems kind of pointless to add ZFS, i would much prefer to see ext4 or Btrfs or something more useful for desktop computing, ZFS is much slower than the aforementioned FS’s too.

[quote=fortheloveofhaiku]I can’t fault BFS, but the option would be great. Is it not just a case of porting the BSD version of Btrfs over to Haiku? I run ext4, XFS, ReiserFS and Btrfs on my computers and BtrFS is noticeably better in terms of I/O performance.

ZFS will add features that would be required if Haiku where a server orientated OS but its not at all. It seems kind of pointless to add ZFS, i would much prefer to see ext4 or Btrfs or something more useful for desktop computing, ZFS is much slower than the aforementioned FS’s too.[/quote]

I don’t really get into filesystems semantics to much. Honestly I just don’t care enough to be bothered. If I had my way there would be one filesystem and tht would be the end of that. Just for sanitys sake one filesystem design makes everyones life easier.

Problem is that evolution of design keeps changing to bring new features, less overhead, better data protection etc etc etc.

ZFS might be a server file system, but BFS kind of has some similar attributes to a good server file system itself.

I am sure the devs would welcome patchs however for the btrfs.

If there where only one FS it would do every thing, but mediocrely. I wish there where maybe 2 or 3 one for each category of computing. Ill give the documentation a look over for Btrfs under BSD and see if i can’t create a patch (don’t expect much though)

I disagree on the mediocirty part, if all resources focused to create one desktop filesystem, you would get one very good desktop file system. The problem becomes application needs. Its the maner in which the OS will be used that makes the file system good or bad. But I do think with some very forward looking design that one best filesystem could be achieved, for the hardware of today.

I have actually read up on this a while ago, characteristics that make a file system good for use on the desktop make it bad for use on the server, and the same things that make a filesystem good for disk usage make it bad for solid state disks, there are trade offs you see, i can’t really remember what they are to be honest but as far as i remember I’m right haha

I do how ever agree that within the Haiku project a unified file system would be great. Possibly evolving and modernizing the BFS FS would be a good idea. Hardware has changed in so many ways since Be OS and its time Haiku changed with it :slight_smile: