Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oasis – a small, statically-linked Linux system

github.com

Post reply on HN
Print view View original

21–30 of 288 posts

Re: Oasis – a small, statically-linked Linux system

#21

Post by raesene9 »

znpy wrote: post #15
sluongng wrote: post #9

What 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.

> 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…

A small point on that last bit. The bearssl authors are pretty conservative when it comes to development milestones, I'd guess that their 0.6 would be pretty solid :)

Re: Oasis – a small, statically-linked Linux system

#22

Post by ghotli »

8organicbits wrote: post #18
ghotli wrote: post #13

Earlier quoted context omitted.

I 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 do…

> 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/

Agreed, 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.

Re: Oasis – a small, statically-linked Linux system

#23

Post by zshrc »

kentonv wrote: post #20

Doesn'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".

musl 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.

Re: Oasis – a small, statically-linked Linux system

#24

Post by peter_d_sherman »

I'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/)

sbase instead of coreutils (https://git.suckless.org/sbase/file/README.html)

ubase instead of util-linux (https://git.suckless.org/ubase/file/README.html)

pigz instead of gzip (https://zlib.net/pigz/)

mandoc instead of man-db (https://mandoc.bsd.lv/)

bearssl instead of openssl (https://bearssl.org/)

oksh instead of bash (https://github.com/ibara/oksh)

sdhcp instead of dhclient or dhcpcd (https://core.suckless.org/sdhcp/)

vis instead of vim or emacs (https://github.com/martanne/vis)

byacc instead of bison (https://invisible-island.net/byacc/)

perp and sinit instead of sysvinit or system 44 (http://b0llix.net/perp/ https://github.com/wereHamster/perp https://troubleshooters.com/linux/diy/suckless_init_on_plop....)

netsurf instead of chromium or firefox (https://www.netsurf-browser.org/)

samurai instead of ninja (https://github.com/michaelforney/samurai)

velox instead of Xorg (https://github.com/michaelforney/velox)

netbsd-curses instead of ncurses (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!" :-) )

Re: Oasis – a small, statically-linked Linux system

#25

Post by skywal_l »

zshrc wrote: post #23
kentonv wrote: post #20

Doesn'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".

musl 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.

And using LTO[0] can also help.

[0]https://gcc.gnu.org/wiki/LinkTimeOptimization

Re: Oasis – a small, statically-linked Linux system

#26

Post by [deleted] »

peter_d_sherman wrote: post #24

I'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/ ) sbase instead of coreutils ( https://git.suckless.org/sbase/file/README.html ) ubase instead of util-linux ( https://git.suckless.org/ubase/file/README.html ) pigz instead of gzip ( https://zlib.net/pigz/ ) mandoc instead of man-db ( https…

[deleted]

Re: Oasis – a small, statically-linked Linux system

#27

Post by znpy »

raesene9 wrote: post #21
znpy wrote: post #15

Earlier quoted context omitted.

> 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…

A small point on that last bit. The bearssl authors are pretty conservative when it comes to development milestones, I'd guess that their 0.6 would be pretty solid :)

> I'd guess that their 0.6 would be pretty solid :)

Would you accept that kind of reasoning for software running on your pacemaker, or on your insuline pump?

I think we should respect the developers here: they're not claiming production quality level (they're claiming beta-quality level) so it's not correct to use that library in any kind of product and claim any kind of production-level quality.

Re: Oasis – a small, statically-linked Linux system

#28

Post by skywal_l »

sluongng wrote: post #9

What 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.

glibc is LGPL. Static linking your application implies some obligation on your part. Musl being MIT is less restrictive.

Re: Oasis – a small, statically-linked Linux system

#29

Post by malux85 »

dijit wrote: post #4

I 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.

Thats a cool idea! Will you open source it or make it available somehow? I would like to play with it for running Atomic T
Post reply on HN