kylequest

TLDR facts about Docker Sandboxes (based on its install): Uses ContainerD compiled natively for Mac OS and uses Nerdbox for the VMs:

├── bin

│ └── sbx

├── libexec

│ ├── containerd-shim-nerdbox-v1 <- Nerbox integration for ContainerD

│ ├── mkfs.erofs

│ ├── mkfs.ext4

│ ├── nerdbox-kernel-arm64

│ └── nerdbox-rootfs-arm64.erofs

More info about Nerdbox is here https://github.com/containerd/nerdbox

Also some WASM there too... though WASM is mostly limited to Tree Sitter for language parsing. Not touching those in phase 1 :-)

By the way, I reversed engineered the Claude Code binary and started sharing different code snippets (on twitter/bluesky/mastadon/threads). There's a lot of code there, so I'm looking for requests in terms of what part of the code to share and analyze what it's doing. One of the requests I got was about the LSP functionality in CC. Anything else you would find interesting to explore there?

I'll post the whole thing in a Github repo too at some point, but it's taking a while to prettify the code, so it looks more natural :-)

Nice and simple interface! Congrats!

There are a number of web/SaaS based vulnerability scanners out there actually :) Snyk's SaaS does it, for example. Free to sign up, free to use. My company's SaaS also provides container scanning with Grype and Trivy. There was another free web-based tool I found a while ago too (forgot the name... will look for it).

Quite a few vulnerabilities don't have CVEs. You can find some of them in the Github Security Advisories.

You are oversimplifying it picking comp as a single/only dimension. There's so much more to being in a startup. That's ok. For some people maximizing current comp is the most important thing. Others have a more long term game where working at a startup with lower comp opens up new opportunities later on (even if the startup equity doesn't work out). For other people it's about feeling alive... What's the point of higher comp at a big company if you hate your life (or, in a less extreme case, where you just don't feel fulfilled or satisfied)...

Slim.AI | CTO Innovation Office R&D Engineer | Full-time | Remote or WA State

I'm the CTO/founder. I also created SlimToolkit (aka DockerSlim), which recently became a CNCF Sandbox project. If you have a background and passion for container internals, cloud native technology and security this might be an interesting role for you. I'm looking for an engineer (the exact title depends on your background/experience) to join the CTO Innovation Office team to work on advanced research projects and experiments. There'll be AI related experiments too :-)

If you think it's a good match for you and you want to learn more email me: cto@slim.ai

Wonder if anybody is really using buildpacks... The stats i've seen recently show that it doesn't have much adoption and I'm very curious why it's not adopted more.

The post also doesn't mention SlimToolkit (aka DockerSlim), which is now a CNCF Sandbox project. It represents another major way to create minimal container images.

Cool to see that people still find "50 Shades of Go" useful :) If anybody has additional gotchas you want to share I'd love to add them!

Slim.AI | Sr Backend Engineers | REMOTE or Seattle/Bellevue/WA | Full-time | Golang, AWS, Containers

I'm the founder and CTO at Slim.AI. I created DockerSlim as a hackathon project and it turned into a journey to help devs building containerized cloud-native apps. We are still early stage, but we are fortunate enough to have 40M+ to support our mission.

Our engineering team is the innovation engine for our product because we are building a solution to solve our own problems creating and running containerized cloud-native applications.

We use Golang, Serverless/Lambda and containers. More about us and the role on our eng github page ( https://github.com/slim-ai/engineering/blob/master/roles/bac... ).

We don't do Leetcode or the usual trivia-based puzzles and whiteboarding interviews. We customize the interview process based on the candidates and their background to make sure we get to learn as much possible and to see how working together can be mutually beneficial.

Our Engineering Principles:

* We use what we build.

* We share a common cloud-native mindset and a platform thinking DNA.

* We create stage appropriate designs that can evolve and that can be thrown away when necessary.

* We optimize for evolvable architecture building an extensible and composable system with disposable components using an API first approach.

* We optimize our designs for people first and machines second.

* We care about the entire system we are building considering the needs of our teammates and the impact of the design decisions we make.

* We learn together.

* We share knowledge and give back to the tech community.

* We have a written down and transparent culture that enables our remote first asynchronous approach to engineering.

* We have a lightweight engineering process based on trust, self-alignment and visibility.

Email me at cto@slim.ai if you'd like to learn more.

Alpine's libc is intentionally non-standard* and Alpine (at least, some of their members) explicitly state that Alpine is not GNU Linux while most other distros people use are :)

distroless is picking up a lot of interest especially with its recent uptick in its adoption in the kubernetes community.

One word... libc :-) There's tons of info on the internet about the gotchas in Alpine. Even fly.io gave up on using/supporting Alpine based container images and they are probably one of the most competent and capable engineering teams out there.

Seems like today is the day of misconceptions for docker-slim on HackerNews :-) Happy to answer any questions. AMA

One thing I'd like to mention right away is that docker-slim doesn't do function level code elimination and that simplifies what it needs to do in a significant way.

There's always a trade off. You are willing to do more low level work "manually" assembling container images your way with apko. You are also willing to accept Alpine randomly exploding in your face :) Different people have different preferences in terms of what risks they will take. For example, I wouldn't use Alpine even if somebody paid me money to use it :) That's because Alpine is not a standard Linux distro and you need to be able to "own" it with all of it's gotchas and incompatibilities. Not everybody is capable of doing that. I know I'm not that good :-) In other cases people can't change their base images.

Please explain how it's wrong without simply saying you prefer other solutions, which was the case with Ariadne :) Dead code elimination is a common construct in software engineering. There's nothing magical about apps and their dependencies. They are relatively straight forward to identify and for the web apps with static assets there are helpers to help you ensure you got everything.

Slim.AI | Backend Engineers | REMOTE or Seattle/Bellevue/WA | Full-time | Golang, Cloud-Native

I'm the founder and CTO at Slim.AI. I created DockerSlim as a hackathon project and it turned into a journey to redefine how DevOps is done for devs building cloudnative apps. We are still early stage, but we are fortunate enough to have 40M+ to support our mission.

Our engineering team is the innovation engine for our product because we are building a solution to solve our own problems creating and running containerized cloud-native applications.

We use Golang, Serverless/Lambda and containers. More about us and the role on our eng github page ( https://github.com/slim-ai/engineering ).

Our Interview Process:

We don't do Leetcode or the usual trivia-based puzzles and whiteboarding interviews. We customize the interview process based on the candidates and their background to make sure we get to learn as much possible and to see how working together can be mutually beneficial.

Our Engineering Principles:

* We use what we build.

* We share a common cloud-native mindset and a platform thinking DNA.

* We create stage appropriate designs that can evolve and that can be thrown away when necessary.

* We optimize for evolvable architecture building an extensible and composable system with disposable components using an API first approach.

* We optimize our designs for people first and machines second.

* We care about the entire system we are building considering the needs of our teammates and the impact of the design decisions we make.

* We learn together.

* We share knowledge and give back to the tech community.

* We have a written down and transparent culture that enables our remote first asynchronous approach to engineering.

* We have a lightweight engineering process based on trust, self-alignment and visibility.

Email me at cto@slim.ai if you'd like to learn more.

Slim.AI | Backend Engineers | REMOTE or Seattle/Bellevue/WA | Full-time | Golang, Cloud-Native

I'm the founder and CTO at Slim.AI. I created DockerSlim as a hackathon project and it turned into a journey to redefine how DevOps is done for devs building cloudnative apps. We are still early stage, but we are fortunate enough to have 40M+ to support our mission.

Our engineering team is the innovation engine for our product because we are building a solution to solve our own problems creating and running containerized cloud-native applications.

We use Golang, Serverless/Lambda and containers. More about us and the role on our eng github page ( https://github.com/slim-ai/engineering ).

Our Interview Process:

We don't do Leetcode or the usual trivia-based puzzles and whiteboarding interviews. We customize the interview process based on the candidates and their background to make sure we get to learn as much possible and to see how working together can be mutually beneficial.

Our Engineering Principles:

* We use what we build.

* We share a common cloud-native mindset and a platform thinking DNA.

* We create stage appropriate designs that can evolve and that can be thrown away when necessary.

* We optimize for evolvable architecture building an extensible and composable system with disposable components using an API first approach.

* We optimize our designs for people first and machines second.

* We care about the entire system we are building considering the needs of our teammates and the impact of the design decisions we make.

* We learn together.

* We share knowledge and give back to the tech community.

* We have a written down and transparent culture that enables our remote first asynchronous approach to engineering.

* We have a lightweight engineering process based on trust, self-alignment and visibility.

Email me at cto@slim.ai if you'd like to learn more.

Slim.AI | Fullstack and Backend Engineers | REMOTE, international or Seattle/Bellevue/WA | Full-time | Golang, Node.js, Vue.js/Nuxt.js

I'm the founder and CTO at Slim.AI. I created DockerSlim as a hackathon project and it turned into a journey to redefine how DevOps is done for devs building cloudnative apps. We are still early stage, but we are fortunate enough to have 40M+ to support our mission.

Our engineering team is the innovation engine for our product because we are building a solution to solve our own problems creating and running containerized cloud-native applications.

We use Golang, Node.js Serverless/Lambda and containers. We have technical writer, frontend, backend and fullstack roles ( https://github.com/slim-ai/engineering ).

Our Interview Process:

We don't do Leetcode or the usual trivia-based puzzles and whiteboarding interviews. We customize the interview process based on the candidates and their background to make sure we get to learn as much possible and to see how working together can be mutually beneficial.

Our Engineering Principles:

* We use what we build.

* We share a common cloud-native mindset and a platform thinking DNA.

* We create stage appropriate designs that can evolve and that can be thrown away when necessary.

* We optimize for evolvable architecture building an extensible and composable system with disposable components using an API first approach.

* We optimize our designs for people first and machines second.

* We care about the entire system we are building considering the needs of our teammates and the impact of the design decisions we make.

* We learn together.

* We share knowledge and give back to the tech community.

* We have a written down and transparent culture that enables our remote first asynchronous approach to engineering.

* We have a lightweight engineering process based on trust, self-alignment and visibility.

Email me at cto@slim.ai if you'd like to learn more.

P.S.

Take a look at DockerSlim ( https://github.com/docker-slim/docker-slim ) if you are interested in working on the open source project that powers our SaaS.

And the gethostbyname() calls might be in a dependency of another dependency and that's when the real fun begins :)

You can try using the xray command that will give you clues (docker-slim isn't just minification :-)). The diff capability in the Slim web portal is even more useful (built on top of xray).

it'll be possible to do something like that in the future where docker-slim will generate a spec that describes what your system and app package managers need to install. Using the standard package managers will be tricky for partial package installs though because it's pretty common that the app doesn't need the whole package. Even now docker-slim gives you a list of files your app needs, but the info is too low level to be usable by the standard package management tools.

Layers support in docker-slim is something that's on the todo list (exact time is tbd).

The recent set of the engine enhancements reduce the need for the explicit include flags. Also new application-specific include capabilities are wip (already added a number of new flags for node.js, next.js and nuxt.js applications).

Slim.AI | Fullstack/Frontend/Backend Engineers | REMOTE, international or Seattle/Bellevue/WA | Full-time | Golang, Node.js, Vue.js/Nuxt.js

I'm the founder and CTO at Slim.AI. I created DockerSlim as a hackathon project and it turned into a journey to redefine how DevOps is done for devs building cloudnative apps. We are still early stage, but we are fortunate enough to have 40M+ to support our mission.

Right now we are focusing on simplifying and accelerating the containerized app delivery (it's too hard, too complicated and with too much manual work). We are about to transition to the next phase and we are expanding our engineering team.

Our engineering team is the innovation engine for our product because we are building a solution to solve our own problems creating and running containerized cloud-native applications.

We use Golang, Node.js Serverless/Lambda and containers. We have technical writer, frontend, backend and fullstack roles ( https://github.com/slim-ai/engineering ).

Our engineering principles:

* We use what we build.

* We share a common cloud-native mindset and a platform thinking DNA.

* We create stage appropriate designs that can evolve and that can be thrown away when necessary.

* We optimize for evolvable architecture building an extensible and composable system with disposable components using an API first approach.

* We optimize our designs for people first and machines second.

* We care about the entire system we are building considering the needs of our teammates and the impact of the design decisions we make.

* We learn together.

* We share knowledge and give back to the tech community.

* We have a written down and transparent culture that enables our remote first asynchronous approach to engineering.

* We have a lightweight engineering process based on trust, self-alignment and visibility.

Email me at cto@slim.ai if you'd like to learn more.

One of the future capabilities will be auto-generating base images. It'll require several images to figure out the right base image. The easy version of it be will be available in Slim SaaS (it'll have enough data for it). Happy to chat more about the details.

Slim.AI | Technical Writer and Fullstack/Backend Engineers | REMOTE, international or Seattle/Bellevue/WA | Full-time | Golang, Node.js, Vue.js/Nuxt.js

I'm the founder and CTO at Slim.AI. I created DockerSlim as a hackathon project and it turned into a journey to redefine how DevOps is done for devs building cloudnative apps. We are still early stage, but we are fortunate enough to have 40M+ to support our mission.

Right now we are focusing on simplifying and accelerating the containerized app delivery (it's too hard, too complicated and with too much manual work). We are about to transition to the next phase and we are expanding our engineering team.

Our engineering team is the innovation engine for our product because we are building a solution to solve our own problems creating and running containerized cloud-native applications.

We use Golang, Node.js Serverless/Lambda and containers. We have technical writer, frontend, backend and fullstack roles ( https://github.com/slim-ai/engineering ).

Our engineering principles:

* We use what we build.

* We share a common cloud-native mindset and a platform thinking DNA.

* We create stage appropriate designs that can evolve and that can be thrown away when necessary.

* We optimize for evolvable architecture building an extensible and composable system with disposable components using an API first approach.

* We optimize our designs for people first and machines second.

* We care about the entire system we are building considering the needs of our teammates and the impact of the design decisions we make.

* We learn together.

* We share knowledge and give back to the tech community.

* We have a written down and transparent culture that enables our remote first asynchronous approach to engineering.

* We have a lightweight engineering process based on trust, self-alignment and visibility.

Email me at cto@slim.ai if you'd like to learn more.

P.S.

Take a look at DockerSlim ( https://github.com/docker-slim/docker-slim ) if you are interested in working on the open source project that powers our SaaS.

Slim.AI | Fullstack and Backend Engineers | REMOTE, international or Seattle/Bellevue/WA | Full-time | Golang, Node.js, Vue.js/Nuxt.js

I'm the founder and CTO at Slim.AI. We are a well funded seed stage startup (9M+) in the developer tooling space. Our mission is to simplify and accelerate the containerized app delivery (it's too hard, too complicated and with too much manual work). We are about to transition to the next phase and we are expanding our engineering team.

Our engineering team is the innovation engine for our product because we are building a solution to solve our own problems creating and running containerized cloud-native applications.

We use Golang, Node.js Serverless/Lambda and containers. We have frontend, backend and fullstack roles ( https://github.com/slim-ai/engineering ).

Our engineering principles:

* We use what we build.

* We share a common cloud-native mindset and a platform thinking DNA.

* We create stage appropriate designs that can evolve and that can be thrown away when necessary.

* We optimize for evolvable architecture building an extensible and composable system with disposable components using an API first approach.

* We optimize our designs for people first and machines second.

* We care about the entire system we are building considering the needs of our teammates and the impact of the design decisions we make.

* We learn together.

* We share knowledge and give back to the tech community.

* We have a written down and transparent culture that enables our remote first asynchronous approach to engineering.

* We have a lightweight engineering process based on trust, self-alignment and visibility.

Email me at cto@slim.ai if you'd like to learn more.

P.S.

Take a look at DockerSlim ( https://github.com/docker-slim/docker-slim ) if you are interested in working on the open source project that powers our SaaS.

Lots of good eBPF info from eBPF Summit: https://ebpf.io/summit-2021/ and https://ebpf.io/summit-2020/

Also videos from eBPF Day KubeCon 2021: https://www.youtube.com/playlist?list=PLj6h78yzYM2Pm5nF_GmNQ...

What kind of images do you have? App images or base images? What's the stack for your image if it's an app image? Is it a server app or a cli app? Do you mind sharing your failures?

By the way, have you looked at the examples? https://github.com/docker-slim/examples Wonder which example is close enough to what you have.

Depending on the command you choose (e.g., "build" or "xray") it's doing different things. With "xray" it's all static analysis where it saves the images and then it analyses it internals. With "build" it performs static and dynamic analysis where it creates a temporary instance of your container. By default, it assumes it's a server app and it'll try to probe your server app when it's running.

I'm curious how others are using the recently added support for compose. Happy to answer any questions you might have.

Slim.AI | Backend and Fullstack Engineers | REMOTE, international or Seattle/Bellevue/WA | Full-time | https://github.com/slim-ai/engineering

We are a well funded seed stage startup (9M+) in the developer tooling space on a mission to redefine how DevOps is done for containerized apps (it's too hard, too complicated and with too much manual work). We are about to transition to the next phase and we are expanding our engineering team.

Our engineering team is the innovation engine for our product because we are building a solution to solve our own problems creating and running containerized cloud-native applications.

We use Golang, Node.js Serverless/Lambda and containers. Take a look at the backend ( https://github.com/slim-ai/engineering/blob/master/roles/bac... ) and fullstack ( https://github.com/slim-ai/engineering/blob/master/roles/ful... ) roles and our engineering principles to see if the role and how we do engineering looks interesting to you ( https://github.com/slim-ai/engineering#engineering-principle... ).

Email me at cto@slim.ai if you'd like to learn more.

P.S.

And take a look at DockerSlim ( https://github.com/docker-slim/docker-slim ) if you are interested in working on the open source project that powers our SaaS.