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

161–170 of 233 posts

Re: Stali: A new static Linux distribution

#161

Post by kbenson »

JdeBP wrote: post #156
kbenson wrote: post #25

Earlier quoted context omitted.

> Since when were politicians even comparable to programs? Since people learned the power of the metaphor. > Do we "elect" a init system For some distros? Sure. By its nature, Linux, GNU and the open source software that goes into the ecosystem allows people to create new distributions, or choose one of the many that exist. This choice is, in some small way, like a vote. If systemd was really that bad, enough people…

Actually, it was a simile, not a metaphor.

Yeah, I'm aware, and actually thought of that while writing the comment, and specifically chose metaphor. I think it still worked better to use metaphor because I think that's the more common way to relate the items in question, and being the more abstract of the two, metaphors obviously allow for similes.

Re: Stali: A new static Linux distribution

#162

Post by 0xcde4c3db »

modifieddog wrote: post #52
arjun1296 wrote: post #33

Earlier quoted context omitted.

I refuse to believe that disk space is less as it can leverage other libraries in the deps list to load at run time and other can use it too. For static executable the same dependent library will have to linked to all binaries. Maintenance is a pain in the neck.

> I refuse to believe that disk space is less as it can leverage other libraries in the deps list to load at run time and other can use it too. If I remember correctly, the argument goes someting like this: modern compilers, i.e. something as recent as the Plan 9 toolchain or a GCC version from this millenium, usually compile in only the necessary code with static linking, and not whole libraries. With dynamic linkin…

> you always have to load the whole library into memory

Not really. You do have to mmap it, but it can be demand-paged (executables are handled this way on most modern systems, which is why compressed executables are usually a bad idea). IIRC, what saves time is mostly not having to do the actual linking part where the references are resolved. This can be precomputed and stashed in the binary (an optimization well-known to Gentoo+KDE users), but that confuses some package managers, breaks some uses of dlopen()/dlsym(), and has issues with ASLR.

Re: Stali: A new static Linux distribution

#163

Post by hollerith »

qznc wrote: post #124
paulddraper wrote: post #28

I really like the idea of static linking. Then I think about how I'd patch the next inevitable openssl bug. Then I don't like it as much.

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

OK, then same question about whatever SSL library it does use.

Re: Stali: A new static Linux distribution

#164

Post by joonoro »

morganvachon wrote: post #14
simophin wrote: post #3

I still don't understand why systemd sucks

That's a loaded question, and I'm only qualified to answer from my perspective and experience. My biggest gripe with it has always been that it is alpha-quality software, even today, that has a central role in an otherwise mature OS ecosystem. It has been widely adopted (some would say forced or tricked into adoption by a few distros) and therefore all the major Linux distributions are now running at an alpha level w…

Out of curiosity, what were you using to measure the speed of the various operating systems you mentioned?

Re: Stali: A new static Linux distribution

#165

Post by JdeBP »

qznc wrote: post #53
copperx wrote: post #47

Earlier quoted context omitted.

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

Google Go and Rust promote it. However, deploying web services is different than Linux distro.

The problem here is that the choice is one extreme or the other, never the happy medium.

The extremes are statically linked everything and dynamically linked everything.

Bryan Cantrill deplores this part of the design of Go. He decries the fact that rather than sitting on top of a HLL-function-call binary interface, with the portability layer being HLL function calls like read(), write(), close(), socket(), execve(), Go produces executables that hardwire one specific instruction set's kernel system call traps.

See https://news.ycombinator.com/item?id=11392119 for his own words.

GCC allows one to selectively statically link various libraries in an otherwise dynamically linked executable. (clang had yet to achieve this functionality, last that I checked a year or so ago.)

Re: Stali: A new static Linux distribution

#166

Post by JdeBP »

qznc wrote: post #49
scott_karana wrote: post #41

Why is static linking supposed to REDUCE memory usage and binary size? Am I missing something really obvious? Eg, if five different binaries are statically linked against the same version of OpenSSL, won't it be in memory and on disk four times more than it would be on a dynamic system?

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.

Re: Stali: A new static Linux distribution

#167

Post by jstimpfle »

gdamjan1 wrote: post #110

"FHS sucks" - and then they make an even worse hierarchy. at least modern distros moved all distro-contents to a single /usr (possibly read-only, snapshoted, etc) mount point. #suckmore

I don't know what a good hierarchy is, but with symlinks it should not be so important where the mountpoints are. So why not keep opportunities to split distro contents into convenient directories living under "/"?

Also separating writable from read-only content, or having volumes with different performance characteristics, makes sense in certain situations. Why not have these mountpoints directly under "/"?

Re: Stali: A new static Linux distribution

#169

Post by jstimpfle »

onli wrote: post #97
JdeBP wrote: post #5

( Also discussed previously at https://news.ycombinator.com/item?id=8819085 and https://news.ycombinator.com/item?id=7261559 ) Interesting points: * http://sta.li/filesystem -- Everything not obviously covered by a fairly simplified hierarchy is put into /sucks , without fixing the problem of /etc still being a grab-bag miscellany. * http://sta.li/filesystem -- /dev being for devices is a "Linux assumption". * http:/…

> 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." The worst thing about that attitude is that the suckless programs I tried are full of bugs and usability problems. I actually liked the idea of building simplified core programs, without the bloat and bc…

> And the whole "we are cool, we configure in source code" is just lazy.

Right. A little config file parsing library does not harm (and can be just copied into the project) but goes a long way for user experience.

Look at icewm, one of my favourite software projects. Yes, it's written in 60K lines of C++, but it's rock solid, fast and flexible. The configuration mechanism is powerful and an example of "no bullshit" design.

Re: Stali: A new static Linux distribution

#170

Post by Tom4hawk »

mort96 wrote: post #66
throwaway2048 wrote: post #64

Earlier quoted context omitted.

commercial unixes haven't been relevant for decades. Unix is linux these days.

How about the second largest desktop OS in the world, OS X (or now macOS)? That's BSD.

Mac OS X is not BSD: https://wiki.freebsd.org/Myths
Post reply on HN