Stripped down image. #109

New Issue

2025-12-29T05:22:33+01:00

adam commented

2025-12-29 05:22:33 +01:00

Originally created by @sickcodes on GitHub (Jan 25, 2021).

Would like to make a full stripped down version.

Ideas to remove:

mail
news
stocks
images
logging(?)
store
screensavers etc.

Outcomes:

faster boot
smaller image size
faster processing
faster Xcode
faster compiling

If anyone has experience in stripping this box down, feel free to post your notes here!

Originally created by @sickcodes on GitHub (Jan 25, 2021). Would like to make a full stripped down version. Ideas to remove: - mail - news - stocks - images - logging(?) - store - screensavers etc. Outcomes: - faster boot - smaller image size - faster processing - faster Xcode - faster compiling If anyone has experience in stripping this box down, feel free to post your notes here!

adam added the enhancement bug labels 2025-12-29 05:22:33 +01:00

adam commented

2025-12-29 05:22:34 +01:00

@xtiankisutsa commented on GitHub (Jan 25, 2021):

In my opinion, the most important stuff in an OSX research environment is safari, itunes, usb passthrough, imessage, app store, xcode and homebrew. At least with those, a lot can be done.

@xtiankisutsa commented on GitHub (Jan 25, 2021): In my opinion, the most important stuff in an OSX research environment is safari, itunes, usb passthrough, imessage, app store, xcode and homebrew. At least with those, a lot can be done.

adam commented

2025-12-29 05:22:34 +01:00

@jonvel commented on GitHub (Jan 26, 2021):

I'd go further - namely not install anything that can be installed 'easily' - so keep the app store and usb passthrough, and whatever else useful that you can't also install through the app store. I'd even forgo homebrew, as much as it pains me, especially as there are competitors like "MacPorts" or "chocolatey". Remember to stay as un-opinionated as possible when non-Mac software is concerned. The basic rule that I'd follow is to not install any application if it can be installed via standard tools (which I think is a CLI or GUI interface to the app store).

@jonvel commented on GitHub (Jan 26, 2021): I'd go further - namely not install anything that can be installed 'easily' - so keep the app store and usb passthrough, and whatever else useful that you can't also install through the app store. I'd even forgo homebrew, as much as it pains me, especially as there are competitors like "MacPorts" or "chocolatey". Remember to stay as un-opinionated as possible when non-Mac software is concerned. The basic rule that I'd follow is to not install any application if it can be installed via standard tools (which I think is a CLI or GUI interface to the app store).

adam commented

2025-12-29 05:22:34 +01:00

@sickcodes commented on GitHub (Jan 26, 2021):

I'd go further - namely not install anything that can be installed 'easily' - so keep the app store and usb passthrough, and whatever else useful that you can't also install through the app store. I'd even forgo homebrew, as much as it pains me, especially as there are competitors like "MacPorts" or "chocolatey". Remember to stay as un-opinionated as possible when non-Mac software is concerned. The basic rule that I'd follow is to not install any application if it can be installed via standard tools (which I think is a CLI or GUI interface to the app store).

Perfect perspective, thank you for sharing that.

You're right, it should probably be reduced to the "netinstall" level and the rest can be automated by the end user from then on out.

While the original version of this project was pretty much a "netinstall", it was an absolute mission to automate, so I've just completed the install.

I agree regarding third-party projects too, especially since this is research tool.

I'll have a go at it over the next few days, if anyone has some tips on culling applications, please do let us know!

@sickcodes commented on GitHub (Jan 26, 2021): > I'd go further - namely not install anything that can be installed 'easily' - so keep the app store and usb passthrough, and whatever else useful that you can't also install through the app store. I'd even forgo homebrew, as much as it pains me, especially as there are competitors like "MacPorts" or "chocolatey". Remember to stay as un-opinionated as possible when non-Mac software is concerned. The basic rule that I'd follow is to not install any application if it can be installed via standard tools (which I think is a CLI or GUI interface to the app store). Perfect perspective, thank you for sharing that. You're right, it should probably be reduced to the "netinstall" level and the rest can be automated by the end user from then on out. While the original version of this project was pretty much a "netinstall", it was an absolute mission to automate, so I've just completed the install. I agree regarding third-party projects too, especially since this is research tool. I'll have a go at it over the next few days, if anyone has some tips on culling applications, please do let us know!

adam commented

2025-12-29 05:22:34 +01:00

@prometheas commented on GitHub (Jan 31, 2021):

So long as the post-install automation is documented (or, indeed, links to the relevant third-party docs are provided in this project's usage docs)... anecdotally, getting up and running today has been a great big whack-a-mole exercise 😅

@prometheas commented on GitHub (Jan 31, 2021): So long as the post-install automation is documented (or, indeed, links to the relevant third-party docs are provided in this project's usage docs)... anecdotally, getting up and running today has been a great big whack-a-mole exercise 😅

adam commented

2025-12-29 05:22:34 +01:00

@sickcodes commented on GitHub (Feb 1, 2021):

So long as the post-install automation is documented (or, indeed, links to the relevant third-party docs are provided in this project's usage docs)... anecdotally, getting up and running today has been a great big whack-a-mole exercise sweat_smile

Sorry I didn't spot that mistake in the documentation!

I'm always reachable on Twitter DM's if it's a more complex question regarding args or if you think there's a problem. Or feel free to post issues :)

@sickcodes commented on GitHub (Feb 1, 2021): > So long as the post-install automation is documented (or, indeed, links to the relevant third-party docs are provided in this project's usage docs)... anecdotally, getting up and running today has been a great big whack-a-mole exercise sweat_smile Sorry I didn't spot that mistake in the documentation! I'm always reachable on Twitter DM's if it's a more complex question regarding args or if you think there's a problem. Or feel free to post issues :)

adam commented

2025-12-29 05:22:35 +01:00

@sickcodes commented on GitHub (Feb 8, 2021):

Observations so far:

Deleting dyld shared cache drastically extends boot time but reduces image size by 2GB
Using qemu-img -c reduces the image the 5GB with no noticeable drawbacks
Removing speech synthesis voice packs reduces image size by 500MB
The image must be mounted inside MacOS due to the inability to mount HFS+ on Linux. This is trivial using -e EXTRA commands

THIRD_DISK=/full/path/to/third_disk.img

docker run #...
-v "${THIRD_DISK}:/image2" \
-e "EXTRA='-device ide-hd,bus=sata.5 ,drive=ThirdDisk -drive id=ThirdDisk,if=none,file=_PATH:/image2,format=qcow2" \

Homebrew adds Xcode command line tools increasing disk size by at least 1GB. I will not be adding this as per valid points made above by @jonvel

I will test these changes and more today and then replace the cloud image with the new semi stripped down image. This will return the cloud docker builds to a passing state as of current I am required to manually build the images and upload them. I have automated that process itself also using DigitalOcean API, however I do not wish to be the Automator, I want hub.docker.com to build the images for us.

Should I cryptographically sign each image from here on on out?

@sickcodes commented on GitHub (Feb 8, 2021): Observations so far: - Deleting dyld shared cache drastically extends boot time but reduces image size by 2GB - Using `qemu-img -c` reduces the image the 5GB with no noticeable drawbacks - Removing speech synthesis voice packs reduces image size by 500MB - The image must be mounted inside MacOS due to the inability to mount HFS+ on Linux. This is trivial using `-e EXTRA` commands ```bash THIRD_DISK=/full/path/to/third_disk.img docker run #... -v "${THIRD_DISK}:/image2" \ -e "EXTRA='-device ide-hd,bus=sata.5 ,drive=ThirdDisk -drive id=ThirdDisk,if=none,file=_PATH:/image2,format=qcow2" \ ``` - Homebrew adds Xcode command line tools increasing disk size by at least 1GB. I will not be adding this as per valid points made above by @jonvel I will test these changes and more today and then replace the cloud image with the new semi stripped down image. This will return the cloud docker builds to a passing state as of current I am required to manually build the images and upload them. I have automated that process itself also using DigitalOcean API, however I do not wish to be the Automator, I want hub.docker.com to build the images for us. Should I cryptographically sign each image from here on on out?

adam commented

2025-12-29 05:22:35 +01:00

@sickcodes commented on GitHub (Feb 15, 2021):

In my opinion, the most important stuff in an OSX research environment is safari, itunes, usb passthrough, imessage, app store, xcode and homebrew. At least with those, a lot can be done.

All of these except for usb and homebrew I will probably have ready soon. Whichever apps can be reinstalled, might be the way to go.

@sickcodes commented on GitHub (Feb 15, 2021): > In my opinion, the most important stuff in an OSX research environment is safari, itunes, usb passthrough, imessage, app store, xcode and homebrew. At least with those, a lot can be done. All of these except for usb and homebrew I will probably have ready soon. Whichever apps can be reinstalled, might be the way to go.

adam commented

2025-12-29 05:22:35 +01:00

@Silfalion commented on GitHub (Feb 18, 2021):

Does it include the fast XCode version? If so I can do tests if you need a volunteer.

@Silfalion commented on GitHub (Feb 18, 2021): Does it include the fast XCode version? If so I can do tests if you need a volunteer.

adam commented

2025-12-29 05:22:35 +01:00

@sickcodes commented on GitHub (Feb 19, 2021):

Does it include the fast XCode version? If so I can do tests if you need a volunteer.

I don't know much about Xcode, sure I would love to see tests

@sickcodes commented on GitHub (Feb 19, 2021): > Does it include the fast XCode version? If so I can do tests if you need a volunteer. I don't know much about Xcode, sure I would love to see tests

adam commented

2025-12-29 05:22:35 +01:00

@Silfalion commented on GitHub (Feb 22, 2021):

Does it include the fast XCode version? If so I can do tests if you need a volunteer.

I don't know much about Xcode, sure I would love to see tests

Sorry, hadn't see your comment earlier. Sure, what would you want me to test?

@Silfalion commented on GitHub (Feb 22, 2021): > > Does it include the fast XCode version? If so I can do tests if you need a volunteer. > > I don't know much about Xcode, sure I would love to see tests Sorry, hadn't see your comment earlier. Sure, what would you want me to test?

adam commented

2025-12-29 05:22:35 +01:00

@sickcodes commented on GitHub (Feb 22, 2021):

Sure, I'm testing all this week ripping the guts out of the system.

Are you referring to Xcode command line tools?

@sickcodes commented on GitHub (Feb 22, 2021): Sure, I'm testing all this week ripping the guts out of the system. Are you referring to Xcode command line tools?

adam commented

2025-12-29 05:22:36 +01:00

@Silfalion commented on GitHub (Feb 22, 2021):

Sounds promising. No, to the GUI version. Did you mean build time speed at the beginning of this issue?

@Silfalion commented on GitHub (Feb 22, 2021): Sounds promising. No, to the GUI version. Did you mean build time speed at the beginning of this issue?

adam commented

2025-12-29 05:22:36 +01:00

@gitcomit8 commented on GitHub (Nov 28, 2022):

Any progress on the stripped down version?

@gitcomit8 commented on GitHub (Nov 28, 2022): Any progress on the stripped down version?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/Docker-OSX-sickcodes#109