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

Sta.li: Static Linux

sta.li

Post reply on HN
Print view View original

11–20 of 99 posts

Re: Sta.li: Static Linux

#11

Post by mcot2 »

davidp wrote: post #10

I'm puzzled by the idea of a system being leaner/faster with n copies of a library in physical RAM rather than 1 copy mapped via VMM into whatever process wants it. IIRC this was the main point of shared libraries, not pluggability or changing code during runtime. Am I missing something?

Maybe if we didn't have gigabytes of RAM these days. I quite like the idea of static linking. It makes software packaging and distribution very very easy and it has some security benefits. Go's build system is a good example of this. This project seems to be dead.

Re: Sta.li: Static Linux

#12

Post by mdwrigh2 »

vinkelhake wrote: post #9

On binary sizes: > Linking a stripped hello world program with glibc results in 600kb. Linking it with uclibc in about 7kb. That's nice for uclibc, but we're typically linking dynamically. The comparison should be between dynamically and statically linked binaries. A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc). There's also a lot of handwaving on memory usage in the FAQ.

> A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc).

Is that the proportional size (binary size + glibc size / number of things using glibc), or just the size of the binary?

Re: Sta.li: Static Linux

#13

Post by khc »

vinkelhake wrote: post #9

On binary sizes: > Linking a stripped hello world program with glibc results in 600kb. Linking it with uclibc in about 7kb. That's nice for uclibc, but we're typically linking dynamically. The comparison should be between dynamically and statically linked binaries. A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc). There's also a lot of handwaving on memory usage in the FAQ.

> There's also a lot of handwaving on memory usage in the FAQ.

Totally. Reading the FAQ reminded me of https://xkcd.com/386/

Re: Sta.li: Static Linux

#14

Post by vinkelhake »

mdwrigh2 wrote: post #12
vinkelhake wrote: post #9

On binary sizes: > Linking a stripped hello world program with glibc results in 600kb. Linking it with uclibc in about 7kb. That's nice for uclibc, but we're typically linking dynamically. The comparison should be between dynamically and statically linked binaries. A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc). There's also a lot of handwaving on memory usage in the FAQ.

> A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc). Is that the proportional size (binary size + glibc size / number of things using glibc), or just the size of the binary?

It's the size of the binary. I don't understand what you mean by proportional size.

If we add more functionality to the hello world program, the dynamically linked version should increase in size slower than the statically linked.

Re: Sta.li: Static Linux

#15

Post by herokusaki »

plorkyeran wrote: post #5
vezzy-fnord wrote: post #2

It's an admirable initiative, but I'm pretty sure that at this point sta.li has been in the "design phase" for years. It's vaporware. I'd love to be proven wrong, though.

© 2006-2013 for something still not released certainly isn't promising. Glancing at the git logs ( http://git.suckless.org/?s=idle ) there is some ongoing work, so the project isn't totally dead at least.

Can you compile the world with static linking on Gentoo Linux or any of the BSDs? If so, that could serve as a substitute.

Re: Sta.li: Static Linux

#16

Post by ChuckMcM »

Ah kids, they crack me up!

Lot of fun reading that, I looked around briefly but couldn't find my email archive from Sun, but I was in the kernel group when folks got the idea that "Gee if you shared the text segment of libraries, that would give you more memory for your buffer cache or user pages!" One of the guys in my group re-wrote the linker to scan through and realign text segments so that the maximum number of read-only pages (and thus shareable) could be allocated. And of course code that had static buffers and what not (go look at the 4.1BSD code, they were everywhere). It made my Sun 3/75 which had, wait for it 32 Megabytes of RAM (yes, less than the L2 cache in some machines these days) run quite a bit faster. Took a long time to get right too.

Shared libraries gave you three distinct advantages, one you cut down on the working set size, two you cut down on file load time, and three it became possible to "interpose" on the library and run two versions of the library at the same time for backwards compatibility.

Building a static system might be fun but for a 64 bit system, building one where libraries were fixed in the address space in flash or something might actually be even better.

Re: Sta.li: Static Linux

#17

Post by cgh »

davidp wrote: post #10

I'm puzzled by the idea of a system being leaner/faster with n copies of a library in physical RAM rather than 1 copy mapped via VMM into whatever process wants it. IIRC this was the main point of shared libraries, not pluggability or changing code during runtime. Am I missing something?

Static linking doesn't necessarily link the entire library, unless the entire thing compiles to a single .o file. Linkers are smart enough to only link in the object files needed by the program. So assuming you are only linking in well-designed libraries, I guess it's possible that statically-linked software will be smaller since it will leave out the stuff you aren't using.

Re: Sta.li: Static Linux

#18

Post by cgh »

I enjoyed this from their description of their dwm window manager, which took me back to the general state of Linux circa 1999:

"Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though."

Re: Sta.li: Static Linux

#19

Post by mdwrigh2 »

vinkelhake wrote: post #14
mdwrigh2 wrote: post #12

Earlier quoted context omitted.

> A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc). Is that the proportional size (binary size + glibc size / number of things using glibc), or just the size of the binary?

It's the size of the binary. I don't understand what you mean by proportional size. If we add more functionality to the hello world program, the dynamically linked version should increase in size slower than the statically linked.

The point of proportional size is to account for the size of glibc, which has to be on disk and in memory and so incurs a cost that isn't accounted for by just looking at the size of the binaries that link against it, by dividing glibc's size by the number of applications that use it.

When examining memory usage on Linux systems, one of the common measurement metrics is the Proportional Set Size (PSS), which essentially is what I was asking about (but for on-disk size, rather than just in-memory): http://lwn.net/Articles/230975/

Re: Sta.li: Static Linux

#20

Post by anabis »

davidp wrote: post #10

I'm puzzled by the idea of a system being leaner/faster with n copies of a library in physical RAM rather than 1 copy mapped via VMM into whatever process wants it. IIRC this was the main point of shared libraries, not pluggability or changing code during runtime. Am I missing something?

In generic distributions it would cause bloat, but in a single purpose embedded device, I found it was a significant size reduction.
Post reply on HN