17 ms·
Oasis – a small, statically-linked Linux system
- deleted 3y ago[deleted]
- __s 3y agomichaelforney was also who did the wayland port of st: https://github.com/michaelforney/st https://github.com/michaelforney/st oasis's predecessor would be https://dl.suckless.org/htmlout/sta.li https://dl.suckless.org/htmlout/sta.li
- sigsev_251 3y agoMichaelforney has also built croc [1], a qbe based C compiler. Really impressive! [1]: https://github.com/michaelforney/cproc https://github.com/michaelforney/cproc
- Koshkin 3y agoNot as "impressive" as TCC, I'd say. Why? TCC has its own backend, and it has the preprocessor built in. (But QBE is indeed impressive.)
- hkt 3y agoThis is very very cool. I love the bloat free nature of the thing, especially velox (the WM). Samurai (build system) also looks pretty interesting. I've not managed to work out quite how samurai works, or truthfully, why it differs from ninja, but this project is exactly the kind of brain food I intend on learning a lot from. Many, many props to Michael Forney.
- dijit 3y agoI cant speak much about the system, it just works, but the community was really nice when I interacted with them over IRC I had the plan to build oasis with bazel for some immutable OS images that could run as kubernetes nodes. I succeeded with a little pointing.
- gravypod 3y agoHave you shared your BUILD files upstream?
- dijit 3y agoNo, they were quite happy with Samurai
- malux85 3y agoThats a cool idea! Will you open source it or make it available somehow? I would like to play with it for running Atomic T
- public_void 3y agoWhy did you need to use bazel?
- dijit 3y agoI didnt need to use bazel, I like bazel and want to learn more about it. I also have a small, but burning, passion for reproducible builds, distributed compilation and distributed caching. Being able to build an entire OS and essentially anything I want on top in a reproducible and relatively organic way (with incremental compilation) is pretty dope.
- i-use-nixos-btw 3y agoYou sound like the perfect Nix cult memb… erm, user. It’s everything you describe and more (plus the language is incredibly powerful compared with starlark). But you speak from sufficient experience that I presume Nix is a “been there, done that” thing for you. What gives?
- eterps 3y agoInteresting choices, finally something that isn't just another Linux distribution.
- nightowl_games 3y agoCan someone explain a couple use cases for something like this?
- ekianjo 3y agoimmutable images
- ghotli 3y agoI routinely get embedded linux devices at $dayjob that need my time and attention and they basically never have the tooling I need to get my job done. I'm a pro at looking at how Alpine builds a tool and then just making my own statically linked / minimal size tool to drop in place on the device. The allure of something like this is that I can just potentially grab a drop-in binary and get on with my day. I simply don't attempt to link to libraries already on the device since they're all built in wildly different ways, old tools, old compilers. Hopefully that's helpful context. Overall since I did linux from scratch half a lifetime ago I've always wondered why something like Oasis hasn't gotten more traction. It's got some ambitious ideas in the README so maybe others have other nice use-cases atop all that. I just see small, statically linked and think 'oh boy if i never have to build my own tools again for some weird board'. If so, I'm here for it.
- 8organicbits 3y ago> grab a drop-in binary This is a cool approach on Docker as well. FROM some:thing AS bins FROM debian:latest COPY --from=bins /bin/foo /bin/
- ghotli 3y agoAgreed, if the binary is statically linked. If you run `file` on the output from that and it shows 'dynamically linked' then you're playing games with porting over libraries, changing the library loading path, or just going full chroot like linux from scratch does with the bootstrapping part of the install. I find static binaries simplest to work with in that context but agreed I use that pattern too with docker and generally build ad-hoc tools within containers like that. If only these devices could run docker but I'm left to my own tooling to figure out per device.
- sluongng 3y agoWhat is the comparison between using musl and traditional glibc? Is there performance differences between the two? I have been seeing musl used more and more in both Rust and Zig ecosystems lately.
- znpy 3y ago> What is the comparison between using musl and traditional glibc? you get weird bugs and failures that don't happen with glibc (like the incomplete dns resolving routines that would fail under some conditions) but you can brag about saving 30-40 mb of disk space. this project seems to be compromising on quality overall, in the name of having smaller size. Even BearSSL, by their own website is beta-quality: "Current version is 0.6. It is now considered beta-quality software" (from https://bearssl.org/ https://bearssl.org/).
- deleted 3y ago[deleted]
- ghotli 3y agohttps://musl.libc.org/releases.html https://musl.libc.org/releases.html I maintain a large codebase, widely deployed, cross compiled to many cpu architecures that's built atop musl. You're right that historically in the context of people blindly using alpine for their container base that sort of thing might be the case. The newest version of musl solves the thing you're describing and in general most of the complaints about malloc perf or otherwise have been addressed. Avoiding musl to me seems like an outdated trope, but there was a time wherein that take was valid indeed.
- NewJazz 3y agomalloc performance is still sub-par IMO. It is not nearly as terrible as it was, but scudo, memalloc, and glibc's malloc are better.
- raverbashing 3y ago
- Koshkin 3y agoThere’s also the “suckless” sta.li
- ratrocket 3y agoA comment up-thread (currently) says/implies Oasis is a successor to sta.li by the same person. https://news.ycombinator.com/item?id=39143029 https://news.ycombinator.com/item?id=39143029 I also thought sta.li when I saw this was about a statically linked linux system...
- Rochus 3y agoInteresting, but what is the use case? What is the advantage of using the croc C compiler instead of e.g. TCC? I wasn't aware of Netsurf (https://www.netsurf-browser.org/); https://www.netsurf-browser.org/); this is really amazing. But it seems to use Duktape as the JS engine, so performance might be an issue.
- helloimhonk 3y agocproc supports C11, tcc only goes up to c99. There is also something to be said for cproc using QBE which is slowly growing backends like risc-v etc which tcc doesnt support afaik.
- Rochus 3y agoOk, thanks, that makes sense. QBE looks interesting, but I'm missing 32 bit support. So currently I'm trying to reuse the TCC backend, which is far from trivial.
- helloimhonk 3y agoThere seems to have been a little progress on that recently, I saw someone working on a ppc 32bit port here: https://bsd.network/@tobhe/111756322928965195 https://bsd.network/@tobhe/111756322928965195 and I also saw somewhere someone working on a 68000 port, but I don't remember where. I'd like an arm 32bit port, which might be a bit easier with this ppc port as an example of 32bit qbe. It'd be nice to try run some hare programs on a gameboy advance :)
- Rochus 3y agoThanks for the hint. The x86 is likely more work and complicated than the existing AMD64. But meanwhile I made significant progress with my TCC backend; currently I design an intermediate representation and binary file format; will publish something on Github in a few weeks.
- cpach 3y ago
- kentonv 3y agoDoesn't linking everything statically imply that the base image -- and memory, at runtime -- will be bloated by many copies of libc and other common libraries? I do like the simplicity of static linking but it sort of seems to go against the idea of avoiding "bloat".
- zshrc 3y agomusl is significantly smaller and "less bloat" than glibc, so even with a statically linked program, it still remains small in both system memory and storage.
- skywal_l 3y agoAnd using LTO[0] can also help. [0]https://gcc.gnu.org/wiki/LinkTimeOptimization https://gcc.gnu.org/wiki/LinkTimeOptimization
- Shorel 3y agoIn a world where Docker and Kubernetes exist, where whole copies of operating systems are added to each running service... This seems a weird thing to complain about =)
- kentonv 3y agoI mean, if you ran every single executable on your desktop in a separate container I think you'd see problems. There are a pretty large number of programs running on most desktops, plus all the programs that get called by shell scripts, etc. Running a handful of containers representing major applications is more reasonable and the memory wastage may be worth it to avoid dependency conflicts.
- drakenot 3y agoYou've just described Qubes OS!
- 3y ago
- peter_d_sherman 3y agoI've added links to the below quote: >"oasis uses smaller and simpler implementations of libraries and tools whenever possible: musl instead of glibc (https://www.musl-libc.org/ https://www.musl-libc.org/) sbase instead of coreutils (https://git.suckless.org/sbase/file/README.html https://git.suckless.org/sbase/file/README.html) ubase instead of util-linux (https://git.suckless.org/ubase/file/README.html https://git.suckless.org/ubase/file/README.html) pigz instead of gzip (https://zlib.net/pigz/ https://zlib.net/pigz/) mandoc instead of man-db (https://mandoc.bsd.lv/ https://mandoc.bsd.lv/) bearssl instead of openssl (https://bearssl.org/ https://bearssl.org/) oksh instead of bash (https://github.com/ibara/oksh https://github.com/ibara/oksh) sdhcp instead of dhclient or dhcpcd (https://core.suckless.org/sdhcp/ https://core.suckless.org/sdhcp/) vis instead of vim or emacs (https://github.com/martanne/vis https://github.com/martanne/vis) byacc instead of bison (https://invisible-island.net/byacc/ https://invisible-island.net/byacc/) perp and sinit instead of sysvinit or system 44 (http://b0llix.net/perp/ http://b0llix.net/perp/ https://github.com/wereHamster/perp https://github.com/wereHamster/perp https://troubleshooters.com/linux/diy/suckless_init_on_plop.htm https://troubleshooters.com/linux/diy/suckless_init_on_plop....) netsurf instead of chromium or firefox (https://www.netsurf-browser.org/ https://www.netsurf-browser.org/) samurai instead of ninja (https://github.com/michaelforney/samurai https://github.com/michaelforney/samurai) velox instead of Xorg (https://github.com/michaelforney/velox https://github.com/michaelforney/velox) netbsd-curses instead of ncurses (https://github.com/sabotage-linux/netbsd-curses https://github.com/sabotage-linux/netbsd-curses)" (Oh, and not to quote Dwayne "The Rock" Johnson's character "Maui" from Disney's Moana or anything -- but "You're welcome!" <g> :-) <g>)
- deleted 3y ago[deleted]
- malux85 3y agoAnyone have a link to the QEMU tarball in the README? It is hosted on a private server and it looks like it's been HN hugged
- lordwiz 3y agoInteresting, Like how its focused on making it lean by having less bloated versions of the tools
- schemescape 3y agoDoes anyone know how big the base installation is? I couldn't find an answer anywhere, and the link to the QEMU image appears to be broken, currently. I'm curious how it compares to, say, Alpine with a similar set of packages.
- notfed 3y ago> Fast builds that are 100% reproducible. It's unclear to me what "100%" refers to here, but surely it does not include the Linux kernel or drivers? (I've recently read conversations about how difficult this would be.)
- hn_go_brrrrr 3y agoGot a link? Sounds interesting.
- notfed 3y agoHere's a link to a recent HN discussion: https://news.ycombinator.com/item?id=38852616 https://news.ycombinator.com/item?id=38852616 TLDR: Linux kernel doesn't have a stable binary kernel interface. And they don't want one. Given this, the definition of "reproducible build" needs, well, a refined definition, if it includes the Linux kernel. [1] https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst https://www.kernel.org/doc/Documentation/process/stable-api-...
- hn_go_brrrrr 3y agoI don't think these are mutually incompatible. Reproducible builds means the same sources will produce the same results when built twice. The kernel's lack of stability guarantees refers to its evolution over time.
- azornathogron 3y agoI'm no expert, but as an interested amateur I thought the Linux kernel could already be built reproducibly? There is some documentation at least... and I know several Linux distributions have been working on reproducible builds for a long time now - I'd be surprised if there hasn't been good progress on this. https://www.kernel.org/doc/html/latest/kbuild/reproducible-builds.html https://www.kernel.org/doc/html/latest/kbuild/reproducible-b...
- dayjaby 3y ago
- johnea 3y ago[flagged]
- deleted 3y ago[deleted]
- speedgoose 3y agoBearSSL development’s seems to have stopped and it’s lacking TLS1.3. Are there promising alternatives?
- asmvolatile 3y agowolfSSL. Open source, widely used, flexible licensing model, TLS + DTLS 1.3 support, support for all modern ciphers and protocol extensions, extremely tuneable for performance/size, FIPS module, excellent customer support, the list goes on....
- jollyllama 3y agoAnyway, here's wonder -Wall
- notnmeyer 3y agothis is funnier than it has any right to be
- deleted 3y ago[deleted]
- sylware 3y agoFor a real statically-linked linux system, the main issue is GPU support: you must relink all apps _really using_ a GPU, that to include the required GPU drivers. With sound, alsa, it is fine since there is IPC/shared-memory based mixing that whatever the playback/capture devices [dmix/dsnoop]. Static linking is reasonable. (pulseaudio[012] IPC interfaces are bloaty kludges, hardly stable in time, 0..1..2.., not to be trusted compared to the hardcore stability of alsa one able to do a beyond good enough job *and* _real_ in-process low latency hardware access at the same time). x11 and wayland are IPC based, then no issue here neither. But for the GPU, we would need a wayland vulkan3D-inspired set of IPC/shared-memory interfaces (with a 3D enabled wayland compositor). For compute, the interfaces would be de-coupled from the wayland compositor (shared dma-buffers). The good part of this would be to free our system interfaces from the ultra complex ELF (one could choose an excrutiatingly simple executable file format, aka a modern executable file format, but will need compilers/linkers support to help legacy support). There is a middle ground though: everything statically linked, except the apps requiring the GPU driver (for that ELF is grotesquely overkill), still provided as a shared library.
- stefan_ 3y agoTo be fair ELF is complex mostly because of relocations, which are not purely to support shared libraries but also the nowadays ubiquitous PIE. But GPU drivers is a good point; I don't believe you can even statically link them today, you would only be statically linking a shim that tries to find the real driver at runtime.
- sylware 3y agoI am exploring an executable file format of my own (excrutiatingly simple, basically userland syscalls) which is only PIE, and until now, the main real "issue" (not really) is actually the lack of support from compilers for static relative global data init (handled by ELF... which is not there anymore). About the shared libs, well, they are the utility shared libs, and the system interface shared libs. With a mostly statically linked elf/linux distro, all the utility libs would be statically linked, and the system interface shared libs would be statically linked if they have an IPC/shared-mem interface. In the end, only the GPU driver is an issue, namely would stay a shared libs.
- m463 3y agoHow big is it? I could imagine there were unexpected efficiencies. Although dynamic libraries should be able to share an address space, I think with static libraries, the linked might strip out unused routines. also, it might be faster
- alexnewman 3y agoNow I just need them to switch to GitHub actions for the ci/cd
- ratrocket 3y agoThere's a (dead) comment lamenting that you can't access Github with javascript turned off. The Oasis repo seems to be mirrored on sourcehut, though, so if that's more acceptable: https://git.sr.ht/~mcf/oasis https://git.sr.ht/~mcf/oasis
- lproven 3y agoPrevious discussion (Aug 2022): https://news.ycombinator.com/item?id=32458744 https://news.ycombinator.com/item?id=32458744
- transfire 3y agoSomehow this reminds me of Gentoo.
- attentive 3y agoIs this functionally like a desktop/graphic OpenWRT? Wouldn't it be better to pile on OpenWRT?
- trinsic2 3y agoIs the goal of Oasis to reduce the complexity of a system to make it easier to maintain?