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

Stali: A new static Linux distribution

sta.li

Post reply on HN
Print view View original

181–190 of 233 posts

Re: Stali: A new static Linux distribution

#181

Post by hollerith »

notalaser wrote: post #81
copperx wrote: post #47

Earlier quoted context omitted.

Static linking is a virtue now? I don't understand the advantages.

A lot -- maybe not a majority, but a sizeable number of people -- think dynamic linking is potentially exploitable due to its complexity, has real-life deployment problems (e.g. due to applications depending on a specific version of a library, or simply due to complacency in building and distribution) and that the advantages it offered twenty years ago are offset by larger hard drives, better and faster network conne…

>offset by larger hard drives, better and faster network connectivity, and better updating systems.

Static linking puts more pressure on RAM and on each level of cache (because if 2 running programs share the same library, there are now 2 copies of the library contending for those resources) than dynamic linking does.

That strikes me as more important than increased use of the resources you list.

Re: Stali: A new static Linux distribution

#182

Post by degobah »

spoiler wrote: post #140
qznc wrote: post #124

Earlier quoted context omitted.

I guess the "suckless" answer would be to not use OpenSSL.

Who knows, we might soon get SuckleSSL. :) Jokes aside, they have a bizarre philosophy and attitude, especially when you consider their software is most of the time buggy, and… Well, sucky.

It's hard to take them seriously when they include statements like this on their FAQ: "Of course Ulrich Drepper thinks that dynamic linking is great, but clearly that’s because of his lack of experience and his delusions of grandeur."

Re: Stali: A new static Linux distribution

#183

Post by mbel »

JdeBP wrote: post #166
qznc wrote: post #49

Earlier quoted context omitted.

Many applications only use parts of libraries, then the linker can throw the unnecessary parts away.

That doesn't address scott_karana's question, as it doesn't speak to the cost of the necessary parts being duplicated in each executable.

It does address the question indirectly. The implicit argument is that the size of duplicated common parts may be lower than size of single instance of everything that is bundled in OpenSSL. There is no proof however if that's the case.

Re: Stali: A new static Linux distribution

#184

Post by bitwize »

striking wrote: post #18
bitwize wrote: post #11

Earlier quoted context omitted.

Hating systemd is like hating Hillary Clinton at this point. It's well past time to suck it up and make peace with your next init system/President because the only viable alternative(s) are far worse.

I cannot even begin to describe how silly your comment is. Since when were politicians even comparable to programs? Do we "elect" a init system, as one nation united under Torvalds? I'm hoping I was just trolled by an HN-flavored Markov Chain.

In the Linux ecosystem, generally you use whatever the majority supports, or if you use an alternative you assume responsibility for supporting it yourself. Since the majority of distros, and soon the majority of upstream, are supporting systemd, what do you think is going to be used by most commercial Linux deployments?

Re: Stali: A new static Linux distribution

#185

Post by infogulch »

jdc0589 wrote: post #179
jstimpfle wrote: post #173

Earlier quoted context omitted.

Is it practical to make diffs of recompiled binaries? Don't you need to compile to position independent code? Or otherwise make sure that most of the code's position does not change when some statically linked library changes?

Slightly different comparison, but I remember some google project to do this for shipping updates a while ago. Must have been for android, but I can't remember.

Chrome, actually. Called Courgette [1]. This would actually be really awesome to apply to statically-linked distro updates.

[1]: https://www.chromium.org/developers/design-documents/softwar...

Re: Stali: A new static Linux distribution

#186

Post by mbel »

loup-vaillant wrote: post #108
lutusp wrote: post #102

> Achieve better memory footprint than heavyweight distros using dynamic linking and all its problems If this is really effective in reducing executable size, it's supremely ironic, since the original point of dynamic linking was to reduce the overall size of groups of executables by sharing common function libraries.

More likely, they're saying mainstream distros are so bloated even dynamic linking can't save them: dynamic linking does reduce memory footprint, but that only mitigates bloat.

I think that "dynamic linking and all its problems" imply that some of the bloat comes from the dynamic linking itself. At least that's how I read it.

I believe argument here goes beyond the sole fact of introducing dynamic linker and includes the fact that dynamic linking may encourage duplication of functionality in applications ending up in bloated system (on the other hand static linking doesn't seem to do anything to discourage bloat).

Re: Stali: A new static Linux distribution

#187

Post by paulddraper »

Annatar wrote: post #103
4ad wrote: post #90

Earlier quoted context omitted.

It's a complete fallacy that every program that needs crypto needs to link to crypto libraries. Look at how Plan 9 does it, where everything is statically linked, but it's other processes which do crypto. Replace only one binary, and the crypto is fixed for all binaries.

shared object libraries are exactly that, a special case of an ELF executable. Special, in the sense that they are not directly executable by users on the command line, other than that, there is no difference (as regular ELF executables can be compiled as re-entrant, position independent code just like shared object libraries).

Yeah, definitely a po-ta-to distinction.

The real difference between static and dynamic linking is self-contained vs. external dependencies. This dependency can be actual "linking" or it can be inter-process; I don't think that changes the equation.

Re: Stali: A new static Linux distribution

#188

Post by steveklabnik »

qznc wrote: post #127
rkangel wrote: post #112

Earlier quoted context omitted.

I don't know about Go, but Rust doesn't promote it. Rust compiles a whole binary at once (for full program optimisation), but that binary can be a dynamic library or executable. How you then build the operating system on top of that is up to you.

Recently, ripgrep was on the frontpage. It says "Linux binaries are static executables" [0]. If I run ldd on cargo, it spits out the usually glibc dependencies, but Rust libraries are statically linked. It seems to be the default behavior of cargo? I would describe that as "promote static linking". Personally, I don't judge this as good or bad. There is no simple answer. Static linking has clear disadvantage wrt secu…

To elaborate on what burntsushi said:

By default, Rust statically links all Rust code. However, glibc isn't usually statically linked, so Rust doesn't either. You can use musl instead of glibc to get 100% statically linked binaries.

Re: Stali: A new static Linux distribution

#189

Post by Spivak »

kbenson wrote: post #177
qplex wrote: post #133

Earlier quoted context omitted.

The other channel: read the source code yourself before compiling. This actually possible with most suckless projects since they are just a couple of hundred lines of C...

Ignoring the fact that this implies you have to be a programmer that knows how to read C to verify the integrity of the downloads, and that the lines of code in C often correlates directly to complexity of the solution being expressed, this also assumes that an attack vector would be something obvious upon reading the code, and not hidden as a subtle bug which is hard to spot.

> Ignoring the fact that this implies you have to be a programmer that knows how to read C to verify the integrity of the downloads

Don't ignore it, that's the practically the point. This is the perfect example of "don't trust me, trust the code".

From http://dwm.suckless.org/

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

Re: Stali: A new static Linux distribution

#190

Post by justinsaccount »

qwertyuiop924 wrote: post #138
justinsaccount wrote: post #10

Earlier quoted context omitted.

Because people like to complain more than they like to actually build a usable alternative. Edit: here's a great example from one of the links in the other comment: suckless complaining about "sysv removed" in systemd. Link takes you to this changelog entry: "The support for SysV and LSB init scripts has been removed from the systemd daemon itself. Instead, it is now implemented as a generator that creates native sys…

They built many. runit, s6, nosh, bsdinit, openrc. But yeah, it is being blamed for bloating init, because for one thing, cron isn't init's job. And that's just the start.

> cron isn't init's job.

Which is why other platforms started moving from cron to init years ago?

OS X:

> Note: Although it is still supported, cron is not a recommended solution. It has been deprecated in favor of launchd. [1]

Solaris:

> cron has had a long reign as the arbiter of scheduled system tasks on Unix systems. However, it has some critical flaws that make its use somewhat fraught. [...] cron also lacks validation, error handling, dependency management, and a host of other features. [...] The Periodic Restarter is a delegated restarter, at svc:/system/svc/periodic-restarter:default, that allows the creation of SMF services that represent scheduled or periodic tasks. [2]

[1]: https://developer.apple.com/library/content/documentation/Ma...

[2]: https://blogs.oracle.com/SolarisSMF/entry/cron_begone_predic...

Post reply on HN