container2wasm
cortex
container2wasm | cortex | |
---|---|---|
8 | 8 | |
1,825 | 1,635 | |
- | 12.8% | |
9.1 | 9.8 | |
3 days ago | 1 day ago | |
C++ | C++ | |
Apache License 2.0 | GNU Affero General Public License v3.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
container2wasm
-
Apple Introduces M4 Chip
The existence of vscode.dev always makes me wonder why Microsoft never released an iOS version of VSCode to get more users into its ecosystem. Sure, it's almost as locked down as the web environment, but there's a lot of space in that "almost" - you could do all sorts of things like let users run their code, or complex extensions, in containers in a web view using https://github.com/ktock/container2wasm or similar.
-
Show HN: dockerc – Docker image to static executable "compiler"
Unfortunately cosmopolitan wouldn't work for dockerc. Cosmopolitan works as long as you only use it but container runtimes require additional features. Also containers contain arbitrary executables so not sure how that would work either...
As for WASM, this is already possible using container2wasm[0] and wasmer[1]'s ability to generate static binaries.
[0]: https://github.com/ktock/container2wasm
[1]: https://wasmer.io/
- FLaNK Weekly 08 Jan 2024
-
Container2wasm: Convert Containers to WASM Blobs
Really impressed by the depth and breadth of this project, well done!
A particularly interesting part is the socket layer inside the browser. Other people solving this problem have previously used a proxy to a server that does the real socket implementation. This means you can't have a "browser-only" solution.
The author has solved this (for HTTP/S only) by proxying HTTP requests and then re-creating them as fetch requests (details here: https://github.com/ktock/container2wasm/tree/main/examples/n...). I'm very interested in using this approach for my own project Runno (https://runno.dev).
- ktock/container2wasm: Container to WASM converter
cortex
-
Introducing Jan
Jan incorporates a lightweight, built-in inference server called Nitro. Nitro supports both llama.cpp and NVIDIA's TensorRT-LLM engines. This means many open LLMs in the GGUF format are supported. Jan's Model Hub is designed for easy installation of pre-configured models but it also allows you to install virtually any model from Hugging Face or even your own.
-
Ollama Python and JavaScript Libraries
I'd like to see a comparison to nitro https://github.com/janhq/nitro which has been fantastic for running a local LLM.
- FLaNK Weekly 08 Jan 2024
-
Nitro: A fast, lightweight 3MB inference server with OpenAI-Compatible API
Look... I appreciate a cool project, but this is probably not a good idea.
> Built on top of the cutting-edge inference library llama.cpp, modified to be production ready.
It's not. It's literally just llama.cpp -> https://github.com/janhq/nitro/blob/main/.gitmodules
Llama.cpp makes no pretense at being a robust safe network ready library; it's a high performance library.
You've made no changes to llama.cpp here; you're just calling the llama.cpp API directly from your drogon app.
Hm.
...
Look... that's interesting, but, honestly, I know there's this wave of "C++ is back!" stuff going on, but building network applications in C++ is very tricky to do right, and while this is cool, I'm not sure 'llama.cpp is in c++ because it needs to be fast' is a good reason to go 'so lets build a network server in c++ too!'.
I mean, I guess you could argue that since llama.cpp is a C++ application, it's fair for them to offer their own server example with an openai compatible API (which you can read about here: https://github.com/ggerganov/llama.cpp/issues/4216, https://github.com/ggerganov/llama.cpp/blob/master/examples/...).
...but a production ready application?
I wrote a rust binding to llama.cpp and my conclusion was that llama.cpp is pretty bleeding edge software, and bluntly, you should process isolate it from anything you really care about, if you want to avoid undefined behavior after long running inference sequences; because it updates very often, and often breaks. Those breaks are usually UB. It does not have a 'stable' version.
Further more, when you run large models and run out of memory, C++ applications are notoriously unreliable in their 'handle OOM' behaviour.
Soo.... I know there's something fun here, but really... unless you had a really really compelling reason to need to write your server software in c++ (and I see no compelling reason here), I'm curious why you would?
It seems enormously risky.
The quality of this code is 'fun', not 'production ready'.
- Apple Silicon Llama 7B running in docker?
- Is there any LLM that can be installed with out python
What are some alternatives?
webvm - Virtual Machine for the Web
ollama - Get up and running with Llama 3, Mistral, Gemma, and other large language models.
SSH-Snake - SSH-Snake is a self-propagating, self-replicating, file-less script that automates the post-exploitation task of SSH private key and host discovery.
bionic-gpt - BionicGPT is an on-premise replacement for ChatGPT, offering the advantages of Generative AI while maintaining strict data confidentiality
leptos - Build fast web applications with Rust.
csvlens - Command line csv viewer
dioxus - Fullstack GUI library for web, desktop, mobile, and more.
nnl - a low-latency and high-performance inference engine for large models on low-memory GPU platform.
dockerc - container image to single executable compiler
Tribuo - Tribuo - A Java machine learning library
terminal-sunday - Start each new terminal session with a thought-provoking reminder of the time you have to make the most of your life!
hyperfine - A command-line benchmarking tool