I can appreciate the work to shrink the image, but copying the various standardized CLI tools and related library files into the image versus installing them with APK can introduce _many_ compatibility challenges down the road as new base Alpine versions are released which can be difficult to detect if they don't immediately generate total build errors. Using static binary versions of the various CLI tools would be a better approach here, which inevitably means larger base binaries to begin with, again ballooning the docker image size... all for a minimal gain of 14MB overall is not worth it for a production build unless you're working in the most minimal of minimal embedded OS environments, which the inclusion of FZF -and- findutils would already seem to negate since there is so much duplication in functionality between the two tools already.
Overall this approach results in an image so fragile I would never use the resulting product in a high-priority production environment or even just my local dev environment as I want to code in it, not have to fix numerous compatibility issues in my tools all over 14MB of space.
> copying the various standardized CLI tools and related library files into the image versus installing them with APK can introduce _many_ compatibility challenges down the road as new base Alpine versions are released which can be difficult to detect if they don't immediately generate total build errors
I'm maybe missing some context here, so you are saying that the default location of these binaries can change (the one's that get copied directly)? Or is it about the shared libraries getting updated and the tools depending on these libraries will eventually break?
Given that you start out with a 31.4 MB image, I don't honestly think the introduced complexity in your build is worth the it. It's a good lesson, for people would doesn't know about build images and ships an entire build pipeline in their Docker image, for a bash script and a <50 MB image the complexity is a bit weird.
Can't necessarily speak for the author, but here's one thing that can happen:
If the underlying system has a newer version of git than the one freeze-dried into your container, repositories managed there by native-git might be in a new format which container-git can't handle. (There might be some new, spiffier way of handling packs, for instance, or they might have finally managed to upgrade the hash function.) And similar issues potentially arise for everything else you're packaging.
No, what I'm saying is you're blanket copying fully different versions of common library files into operating system lib folders as shown above, possibly breaking OS lib symlinks and/or wholly overwriting OS lib files themselves in the process for _current_ versions used in Alpine OS if they exist now or in the future, potentially destroying OS lib dependencies, and also overwriting the ones possibly included in the future by Alpine OS itself to get your statically copied versions of the various CLI tools your shell script needs to work. The same goes for copying bash, tr, git, and other binaries to OS bin folders. No No NO!
That is _insanely_ shortsighted. There's a safe way to do that and then there is the way you did it. If you want to learn to do it right and are deadset against static binary versions of those tools for the sake of file size, look at how Exodus does it so that they don't destroy OS bin folders and library dependency files in the process of making a binary able to be moved from one OS to another.
This is why I'm saying your resulting docker image is incredibly fragile and something I would never depend on long-term as it's almost guaranteed to crash and burn as Alpine OS upgrades OS bins and lib dependency files in the future. That it works now in this version is an aberration at best and in reality, there probably are things that are broken in Alpine OS that you aren't even aware of because you may not be using the functionality you broke yet.
OS package managers handle dependencies for a reason.
Relax. While I wouldn't recommend OPs approach either. But you're not particularly right either.
Exodus clearly states:
> Exodus is a tool that makes it easy to successfully relocate Linux ELF binaries from one system to another... Server-oriented distributions tend to have more limited and outdated packages than desktop distributions, so it's fairly common that one might have a piece of software installed on their laptop that they can't easily install on a remote machine.
Exodus is specifically designed for moving between different systems.
He is largely moving from the same base image. In the article base layer is `alpine:3.18` and the target image is `alpine:3.18` and in the latter part of the article `scratch` (less to zero conflict surface). One would assume those two would be coupled.
There are other technical merits to not doing what he's doing but you haven't listed any and dismissed his work. I'd venture if you actually knew what you're talking about you'd have better things to add to this conversation than "OS package managers handle dependencies for a reason."
Perhaps next time give some feedback that would help the writer get closer to a well-working exodus like solution. It's hackernews, "dont roll your own" discouragement should be frowned upon.
Fantastic to see this project... hopefully they'll remove all the enterprise cloud and MDM related requirements for using various browser policies (MetricsReportingEnabled,EnterpriseRealTimeUrlCheckMode, etc) along with a re-enabling a few policies that were annoyingly deprecated like the NTP related settings, HomepageIsNewTabPage, HomepageLocation, and easier side-loading of local extensions sources.
This seems like it takes something simple and makes it much more complicated with the aim of making it simple and then fails on all counts. For example, how is this different/better than simply using version controlled docker-compose files instead of flat single image dockerfiles?
This is adding yet another abstraction layer on top of docker which is already a convoluted space with numerous options available. Additionally, the "Balanced control between App Devs and Operators" tagline makes me wonder how "operators" would have a better awareness of how a deployment should operate versus the developers themselves. The developers should be creating their solutions based on previously defined security constraints and compliance requirements, so what "balanced control" is being shifted around here?
If they are virtue signalling losers, that implies a cohort of virtue signalling losers exist in Twitter. About other virtues and other losses. thus, it's losers all the way down.
That's a shame, I was hoping YouTube was going to go all-in with their ad blocker bans at the same time since I would have been hit by that too. The amount of time I've gotten back from no longer wasting time reading tweets since I refuse to create a Twitter account has been absolutely wonderful. I'm looking forward to ditching all the wasted time on YouTube soon as well. These companies don't have a clue.
> "The once-secret program — created after the 9/11 attacks and described by intelligence officials as crucial to stopping overseas hackers, spy services and terrorists — has long faced resistance by Democrats concerned that it could trample on Americans’ civil liberties."
I guess that's why the Democrat Obama opened up access to all NSA raw sigint data to every other federal law enforcement agency (all 16 of 'em) before leaving office. His final f you to American citizens as president (officially). Because he was soooooo concerned about trampling on citizen civil liberties... Right.
Give me a break... the article is obviously a leftist hit piece against the right.
In my experience, a lot of millenials that constantly talk about traveling and how it "fulfills" them are generally trying to replace that empty feeling not having kids has left them with. It's a biological imperative, after all. The one constant you typically hear from people with kids: "i'm exactly where i should be in the world."
In my experience, parents are the only ones who seem to feel this desperate need to push their lifestyle on others. I'm quite happy with my life and although I'm happy to discuss my choices, I have never once felt the need to denigrate those who choose differently.
https://news.ycombinator.com/item?id=39243450