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 :-)
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).
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: [email protected]
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.
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 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.
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.
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 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.
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 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.
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.
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.