starred/Docker-OSX
1
0
Fork 0
mirror of https://github.com/sickcodes/Docker-OSX.git synced 2026-01-11 21:10:25 +01:00
Code Issues 411 Packages Projects Releases Wiki Activity

Stripped down image. #110

New Issue
Open
opened 2025-12-28 23:24:48 +01:00 by adam · 13 comments
adam commented 2025-12-28 23:24:48 +01:00
Owner
Copy Link

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 bugenhancement labels 2025-12-28 23:24:49 +01:00
adam commented 2025-12-28 23:24:50 +01:00
Author
Owner
Copy Link

@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-28 23:24:51 +01:00
Author
Owner
Copy Link

@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-28 23:24:51 +01:00
Author
Owner
Copy Link

@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-28 23:24:52 +01:00
Author
Owner
Copy Link

@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-28 23:24:53 +01:00
Author
Owner
Copy Link

@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-28 23:24:53 +01:00
Author
Owner
Copy Link

@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-28 23:24:54 +01:00
Author
Owner
Copy Link

@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-28 23:24:54 +01:00
Author
Owner
Copy Link

@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-28 23:24:55 +01:00
Author
Owner
Copy Link

@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-28 23:24:55 +01:00
Author
Owner
Copy Link

@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-28 23:24:55 +01:00
Author
Owner
Copy Link

@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-28 23:24:56 +01:00
Author
Owner
Copy Link

@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-28 23:24:57 +01:00
Author
Owner
Copy Link

@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.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
documentation
enhancement
following upstream developments
good first issue
help wanted
invalid
pull-request
Mirrored from GitHub Pull Request
 question
No Label bug enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/Docker-OSX#110
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?